2017年6月26日月曜日

[告知]CDATA API Serverローンチイベントとグローバル企業向けITセミナでIDの話をします

こんにちは、富士榮です。

7月20日(木)と21日(金)に以下2つのセミナで登壇します。
いつも告知が直前すぎるので、今回は早めに告知させていただきます。

1.CDATA Day 2017
 日時  :7月20日(木)15:00~18:00
 申し込み:http://www.cdata.com/jp/events/cdataday17/
 タイトル:アイデンティティAPIとデータ統合プラットフォームの活用
 場所  :日本マイクロソフト株式会社 品川本社 セミナルーム

2.Enterprise IT seminar by professionals from global IT companies
 日時  :7月21日(金)14:30~17:00
 申し込み:https://www.xlsoft.com/jp/products/cdata/seminar.html
 タイトル:Designing cloud-based Identity and Access Management system for global enterprises
 場所  :エクセルソフト株式会社 セミナルーム


それぞれ簡単に内容を紹介します。

まずはCDATA Day 2017からですが、こちらはCDATA社のAPI Serverのローンチイベントということもあり、API Serverを使ってSCIMなどアイデンティティAPIを実装する話をします。(完全SCIM互換にするにはまだ若干機能不足はあるのですが、その部分は今後の期待ということで)
また、元々のCDATAの強みであるデータ統合基盤としてのアダプタの豊富さを利用してプロビジョニングを手軽に実装する方法なども考えられるので、その方面への活用についてもお話しできればと思っています。

先日ドイツで開催されたEuropean Identity & Cloud Conference 2017のKeynoteでOne IdentityのVPであるJackson Shawも話していましたが、現状各種アプリケーションのSCIMへの対応が中々進んでいない中で、ID管理製品側で専用のアダプタを開発するのではなく、データ統合プラットフォーム(クラウドベースのiPaaS/Integration Platform as a Serviceを含む)をID管理システムとターゲットシステムの間に挟む、という構成もあり得ると考えています。

こんな感じです。(出典:European Identity & Cloud Conference 2017 Keynote : When will Identity and Access Management be Digital Transformed – Jackson Shaw / VP One Identity)


この辺りを(できれば)デモを交えながら話せれば、と思います。


次に、翌21日(金)に行われるEnterprise IT Seminarです。
こちらは外資系企業のIT部門や日系企業で現地法人とやり取りをするIT部門の方々を対象として、セキュリティ、ERP/CRM、アプリケーション開発、データ統合の4つのテーマでグローバル・プロジェクトをどのように進めるか、という話があり、私はその中のセキュリティ、アイデンティティ管理のコマを受け持ちます。(全編英語です)

法令の違いはもちろんですが、全体最適に関する考え方のスケールがやはり日本企業の中だけで進めるプロジェクトとは違いますので、利用するツールやサービスの選定を含め色々と考えるべきことが多々あります。また、特にIDaaSの優位性が出やすい領域でもあるので、その辺りの割り切り方などについてもお話しできるといいかな、と思っています。


それでは。会場でお会いしましょう。

2017年6月19日月曜日

[Azure AD] PingAccess連携が正式リリース

こんにちは、富士榮です。

遂にAzure ADとPingAccessとの連携機能が正式リリースされました。Public Preview公開から約3月で正式リリースされたので、かなり早いペースで出てきましたね。
やはり今週シカゴで開催されているCloud Identity Summit(PingIdentity主催)に合わせて来た、というところでしょう。

公式Blogでのアナウンス
 Ping Access for Azure AD is now Generally Available (GA)!
 https://blogs.technet.microsoft.com/enterprisemobility/2017/06/15/ping-access-for-azure-ad-is-now-generally-available-ga/

画像出典:公式blog

出来ることは、Azure AD Web Application Proxyを使ってPingAccessへの認証をAzure ADで行うことにより、PingAccess配下(リバプロ、エージェント)のアプリケーションへのシングルサインオンを実現する、というようなところです。

詳しくは以前紹介したこちらのポストを参照してください。
 [Azure AD]PingAccess連携でオンプレ資産へのアクセスを拡張する
 http://idmlab.eidentity.jp/2017/03/azure-adpingaccess.html

 [Azure AD+PingAccess]Basic認証のあるバックエンドサイトへアクセスする
 http://idmlab.eidentity.jp/2017/03/azure-adpingaccessbasic.html


2017年6月15日木曜日

[Azure AD/Windows 10]外部SAML IdPとID連携しているとAzure AD Joinできない

こんにちは、富士榮です。

今回はかなり、レアかつマニアックな話です。
以前、Office365へOpenAMを使ってログインする方法を紹介しました。

 [Office365/AzureAD]OpenAMとのID連携①
 http://idmlab.eidentity.jp/2014/11/office365azureadopenamid.html


Azure ADは純正の外部IdPであるAD FS以外にもws-federationもしくはSAMLに対応した外部IdPとのフェデレーションもサポートしているので、OpenAMやPingFederateなどのサードパーティIdPでOffice365などAzure ADと連携されているアプリケーションへのログインが可能になる、という事です。

通常のWebアプリケーションであれば問題はないのですが、実はWindows 10のAzure AD Join(いわゆるWorkplace Joinではなく)を外部SAML IdPと連携したAzure ADで実行しようとすると問題が起きます。
(外部IdPがws-federationだと行けます。本国の方々と話をしていたんですが、あまりにもレアケースなので・・・という感じでした。まぁ、確かに。)

ということで、現状はAD FS以外の外部IdPと連携したAzure ADへのWindows 10デバイスの直接参加は不可能なので、もし将来的にAzure AD Joinを行う計画のある人は外部SAML IdPを使うのはやめておいた方が良いかも知れません。
注)AD FSを使う場合も正規の手続き(Convert-MsolDomainToFederated)以外を使った場合(Set-MsolDomainAuthenticationでプロトコルにSAMLを指定)は他の外部SAML IdPと同様にAzure AD Joinが出来なくなります。


では、どんなことが起きるのか、何が原因なのか、について少しだけ解説しておきます。

◆何が起きるのか?

[設定]からAzure ADへの参加を使用とすると「職場または学校のアカウント」の入力を求められます。


正規の手順で構成されたAD FSを使っている場合は、ユーザ名を入力して[次へ]をクリックすると組織のサインインページ(要はAD FSのログイン画面)へ遷移します。


しかし、その他の外部SAML IdPを使っている場合は以下の様に「組織のアカウントではない」と怒られてしまい、Azure AD Joinが出来ません。


◆何が起きているのか?

Azure ADへのサインインを行う際、入力したユーザがどこで認証されるべきか?をドメインパート(@より後ろ)を見て判別する、いういわゆるホームレルムディスカバリというプロセスが実行されます。これは、ブラウザシナリオでも今回のような非ブラウザシナリオでも同様です。

今回ブラウザシナリオでは外部IdPを使ってもログインできて、Azure AD Joinの場合だけダメなのか?はこのホームレルムディスカバリの方法と仕様が異なるためです。

ブラウザシナリオにおいては
 https://login.microsoftonline.com/common/userrealm
というエンドポイントにクエリパラメータに「user=ユーザ名」をつけたGETリクエストを行うのに対し、Azure AD Joinの場合は、
 https://login.microsoftonline.com/common/GetCredentialType
というエンドポイントにユーザ名の情報をPOSTします。
※ちなみにワークプレイスジョイン(組織アカウントの追加)の場合はブラウザシナリオと同じエンドポイントを使うので、外部SAML IdPを使っても問題なくサインインできます。

エンドポイントが異なるのと同様に返ってくるレスポンスも異なり、ブラウザシナリオでは、外部SAML IdPの種類にかかわらず、ちゃんと利用プロトコルと外部SAML IdPのURLを返してきますが、Azure AD Joinの場合は、外部SAML IdPのURLが返ってこず、ここでレルム探しが失敗、先のエラーメッセージが表示されています。

ブラウザシナリオでのレスポンスの例
{
  "NameSpaceType":"Federated",
  "federation_protocol":"SAML20",
  "Login":"hoge@example.net",
  "AuthURL":"https://idp.example.net",
  "DomainName":"example.net",
  "FederationBrandName":"eIdentity",
  "federation_saml_request":"xxxxx",
  "federation_saml_relay_state":"xxxxx",
  "cloud_instance_name":"microsoftonline.com"
  "TenantBrandingInfo":[{"xxxx"}]
}

Azure AD Joinのレスポンスの例(AD FSの場合)
{
  "Username":"hoge@example.net",
  "Display":"hoge@example.net",
  "IfExistsResult":0,
  "Credentials":{
    "PrefCredential":4,
    "HasPassword":true,
    "RemoteNgcParams":null,
    "FederationRedirectUrl":"https://fs.example.net/adfs/ls/?...omit...",
    "EstsProperties":{"xxx"},
    "apiCanary":"xxx"
  }
}

Azure AD Joinのレスポンスの例(外部SAML IdPの場合)
{
  "Username":"hoge@example.net",
  "Display":"hoge@example.net",
  "IfExistsResult":1,
  "Credentials":{
    "PrefCredential":1,
    "HasPassword":true,
    "RemoteNgcParams":null},
    "EstsProperties":{"xxx"},
    "apiCanary":"xxx"
   }
}

上記のように、外部SAML IdPを使っているとFederationRedirectUrlが返ってこないので、フェデレーション先にリダイレクトがされません。

どこかのタイミングでこの挙動も変わるかも知れませんが、取り合えず現状はAzure AD Joinの計画がある場合は、Azure ADだけでサインインするか、AD FSを含む外部ws-federation IdPとして使う、という2択になりそうです。

2017年5月13日土曜日

[Azure AD] Azure AD B2C に OIDC/SAML 対応の外部 IdP が設定可能に

こんにちは、富士榮@ミュンヘンです。

最近何かと熱い分野でもある CIAM(Consumer Identity and Access Management)ですが、今週ドイツ・ミュンヘンで開催された European Identity & Cloud Conference 2017(EIC)でも他のテーマである GDPR、PSD2 などプライバシー系の法令対応の話や 昨年のニューオリンズで開催された Cloud Identity Summit(CIS)でも大きな話題となった Blockchain による信頼できる Identity 基盤と VRM(Vendor Relationship Management)、Respect Network の文脈での Self Sovrin Identity などと並行して大きく取り上げられていました。

そんな中、平行して US で開催されていた Build ではマイクロソフトの CIAM の実装である Azure Active Directory B2C の大きなエンハンスが発表されました。

ポイントは、カスタムの外部 IdP として

  • OpenID Connect の OP をサポート
  • SAML 2.0 の IdP をサポート
したことです。

これまでは Microsoft Account、Facebook、Google、LinkedIn、Amazon.com、などメジャーなコンシューマ ID プロバイダが正式サポート、twitter や Weibo、QQ、WeChat が Preview として対応、という状況でしたが、OpenID Connect および SAML に対応したことで、自分の好きな ID プロバイダをカスタムで追加することが出来るようになりました。

公式なドキュメントでは OpenID Connect 対応の IdP として Azure AD、SAML 対応の ID プロバイダとして salesforce.com を例として構成例が解説されています。

公式ドキュメント

ガリガリと XML を書いてアップロードする必要があるなど、まだまだ手順が面倒なのですが、公式アナウンスでも次の数週間でもう少し簡単な実装方法に対応させる、とありますのでそちらに期待しましょう。

管理画面の Identity Experience Framework - Preview というものが皆さんの Azure AD B2C にも来ているはずです。この中にカスタムポリシーを構成するための機能が詰まっています。



早速 Azure AD を Azure AD B2C のカスタム IdP として追加してみたのが以下の画面です。

色々とカスタマイズの余地もあるので、引き続き触っていきたいと思います。


2017年5月6日土曜日

[Azure AD]条件付きアクセスの信頼済みネットワークが拡張されてました

こんにちは、富士榮です。

永らく条件付きアクセスの信頼済みIPの上限数(50レンジ)に悩まされてきた管理者の皆さんに朗報です。(といってもしばらく前に拡張されていたので、既に気が付いた人は使っていると思いますが)

これまでは、旧MFAポータルで信頼済みIPを設定していたのですが、登録可能な数は50レンジまででした。



この上限で困るケースが社内からのネットワークの出口が事業所毎にあったり、クラウドベースのプロキシサービスを使っているようなケースです。

以前、マイクロソフト・コーポレーションの開発チームとのディスカッションの場でもこの制限に関しては私を含め複数の人から改善リクエストが出ており、名前付きネットワーク・オブジェクトとの統合のロードマップが示されていましたが、条件付きアクセスの設定が正式に新ポータルへ移行されたタイミングで信頼済みIPについても移行されました。

尚、現段階では以下の注意点があります。
・過去に作成したアプリケーションの条件付きアクセスの構成は新ポータルからは見えないので、構成し直す必要があります
・再構成しない場合、過去に作成したアプリケーションについては旧ポータルの信頼済みIPが使われます
・新しくアプリケーションを作成する場合、旧ポータルからアプリケーションを作成する場合でも、条件付きアクセスは旧ポータルからは構成できなくなっています。条件付きアクセスの構成は新ポータルから実施してください


早速ですが、構成を見てみます。

新ポータルの条件付きアクセスの構成にNamed Locationsという項目が存在するので、New locationをクリックしてネットワークの場所を定義していきます。

IPレンジをどんどん追加できます。(画面からの直接入力の場合は10個単位で保存をしないとダメですが、保存した後に再度ネットワーク構成を開いて追加していけばどんどん追加できます)また、テキストファイルにネットワークレンジの一覧を書いてUploadすることで一気に追加することが出来ます。


次はこれを使って条件付きアクセスのルールを構成してみます。

まずは対象のユーザ・グループを選択します。ここでは全員を対象としています。


次に対象とするアプリケーションを選択します。ここでは「pharaoh1234」という名前のアプリケーションを対象としています。

次に、条件を設定します。今回信頼済みIPに設定されていないネットワークからのアクセスの場合は多要素認証を要求しようと思うので、ここのLocationsにInclude:All locations、ExcludeにAll trusted IPsを指定します。



条件に一致した場合のアクションとして多要素認証を要求したいので、以下の通りRequire multi-factor authenticationにチェックを入れます。

後は、ルールをEnableにして保存すると完了です。


この状態で信頼済みIP以外のネットワークからアプリケーションにアクセスすると以下のように多要素認証が要求されます。



2017年4月29日土曜日

[MIM]3月のアップデートでサポートプラットフォームの大幅な改善+α

こんにちは、富士榮です。

色々と追い付いていなかったので、改めてまとめておきます。

3月にMicrosoft Identity Manager 2016 SP1 (MIM)向けのホットフィックスがリリースされ、特にサポートされるプラットフォームが大幅に追加されました。

個人的には、プラットフォームサポート周りでは「SQL Server 2016 Always Onのサポート」が非常に熱いトピックスでしたが、他にもSCSM 2016がサポートされたり、Visual Studio 2017が使えるようになったり、など色々とエンハンスが行われています。

MIM 2016でサポートされるプラットフォーム一覧
https://docs.microsoft.com/en-us/microsoft-identity-manager/plan-design/microsoft-identity-manager-2016-supported-platforms


他にも以下が新しく使えるようになった代表的なシナリオです。



こちらからダウンロード可能なので、MIM使いの皆さんは適用しておきましょう。

2017年4月18日火曜日

今年の de:code はユーザ事例を通して Azure AD 導入の実情をお伝えします

こんにちは、富士榮です。

いつの間にか de:code 2017 まで約1か月となりました。
昨年の de:code ではチョークトークで何でも QA コーナーみたいなセッションを担当しましたが、今年は本職?での株式会社アシックス様の案件事例を通して Azure AD の活用の実際をお伝えします。



これまでも事例をベースにしたセッションはやってきたんですが、実は Azure AD 案件の事例をオープンな場でお話しするのって初めてなんですよね。今回は Azure AD を導入するにあたり Azure Web App や Azure Automation、Express Route など Azure 関連のサービスをそれなりの種類使っていたりしますので、Azure AD 自体の使い方に加えて、その辺りの話も織り交ぜつつグローバル企業におけるクラウド・ベースの認証基盤のあり方や既存環境からのマイグレーションなどについてお話できると良いなぁ、と思っています。

参考)これまでオープンにしてきた IdM 系の事例です。(節操なく色んなベンダの仕事してますね)



どうしても本職絡みだと言えないこともあったりするんですが、今回はなるべく Azure AD の各種技術的な要素が実際の案件ではどのように使われているのか?を皆さんにお伝えすることで、色々とイメージをしてもらえればと思いますので、お手すきの方はぜひお越しください。

あ、2日目の最終コマだったと思います。


尚、今回の de:code ではセキュリティ・トラックが 16 セッションもあり、私の他にも Enterprise Mobility の MVP が大勢出てきてマイクロソフト社員が語れないこと?を語ってくれると思いますので、私自身も非常に楽しみです。

以下、セキュリティ・トラックのセッション一覧です。

セッション番号タイトル担当
SC01DevSecOps on Azure : セキュリティ問題に迅速に対応するためのパイプライン設計MS安納さん
SC02シチュエーション別 Active Directory デザインパターンMVP宮川さん
SC03Active Directory の DR 対策~天災/人災/サイバー攻撃、その時あなたの IT 基盤は利用継続できますか?MVP渡辺さん
SC04あなたのサービスを "ID" で守る! Azure Active Directory の条件付きアクセスの基礎と実装MS松井さん
SC05株式会社アシックス様における Azure AD 導入プロジェクトの実際MVP富士榮
SC06Windows と Azure、2つの Information Protection をディープに解説!MVP国井さん
SC07Azure AD と Ruby で学ぶ OpenID Connect!MVP真武さん(nov)
SC08SDL からビジネスモデルまで IoT セキュリティを俯瞰するMS高橋さん
SC09パッチ待ちはもう古い!Windows 10 最新セキュリティ技術とゼロデイ攻撃攻防の実例MS村木さん
SC10Intune Application Protection を可能にするモバイル アプリ開発MSロバートさん
SC11セキュリティマニアックス ~侵入。ダメ。ゼッタイ。~MS蔵本さん
SC12DevSecOps 時代のセキュリティ人材DIT河野さん
SC13ログ管理で向上させるセキュリティMS山本さん
SC14IoT のセキュリティアーキテクチャと実装モデルMS安納さん
SC15Windows Hello で実現するハイブリッド 生体認証MS小町さん
SC16スパムの脅威から企業を守る!Office 365 で実現するセキュアコラボレーションtwofive末政さん


ちなみに、今年はゴールデンウィーク明けの EIC(European Identity & Cloud Conference 2017)に行こうと思っているので、実はほとんど資料を作る時間がないのが最大の課題です・・・。