2016年3月28日月曜日

OpenID ConnectとSCIMのエンタープライズ利用ガイドライン、(同)実装ガイドライン

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

2013年末に第1版が出てから2年3か月を経て、改訂版の「OpenID Connectのエンタープライズ利用ガイドライン」および「(同)実装ガイドライン」が公開されました。

実装ガイドライン

利用ガイドライン


初版では利用ガイドラインと実装ガイドラインが分離されておらず、若干プロトコル寄りに偏った内容でしたが、今回はエンタープライズにおけるID運用の特徴を踏まえたフェデレーションやプロビジョニングに関する考え方をまとめた「利用ガイドライン」と、OpenID Provierや対応するアプリケーション、SCIMを使ったプロビジョニング・サービスの実装に特化した「実装ガイドライン」を別冊とすることにより、より読み手を意識した構成となっています。

各ガイドラインはOpenID Foundation Japanのホームページからダウンロードできますので、ぜひダウンロードして目を通してください。
 https://www.openid.or.jp/news/2016/03/eiwg-guideline.html

私がエクスジェン・ネットワークスの江川さん、セコムの島岡さんと3名で改訂を担当させていただきました利用ガイドラインの中身を簡単に紹介させていただきますと、

  • なぜフェデレーションが必要なのか?
  • エンタープライズとコンシューマのフェデレーションに関する考え方の違いとプロビジョニングの必要性
  • 標準化されたプロビジョニングAPIの重要性
  • アイデンティティとトラスト、身元保証
  • 権限委譲と代理アクセス、トレンドとしてのUMAの紹介

といったキーワードでまとめています。

また、オージス総研の八幡さん、OpenID Foundation Japanのnov氏らでまとめた実装ガイドラインではOpenID ConnectおよびSCIMのプロトコルの解説からユースケースへの適用、実際のサンプル実装例が解説されており、かなりのボリュームになっています。

ID管理・ID連携の企画~検討を行うIT企画の方にも、サービス実装を行う開発者の方にも役立つ内容となっていると思いますので、是非ダウンロードしてご覧ください。

2016年3月27日日曜日

[Windows 10]スマートフォンでサインインする

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

先日のポストでWindows 10へスマートフォンでサインインする機能について紹介しました。
 [Windows 10]Microsoft Passport for Work 2Goが来たか?

先日はうまく動きませんでしたが、最近公開されたビルド14295にスマートフォンをアップデートしたところ、うまく動くようになりました。

こんな感じで動きます。

では、早速環境を見てみましょう。

◆準備

必要なのは以下のものです。

  • Azure ADのアカウント
  • スマートフォン
    • Windows 10 Mobile 10.0.14295.1000
    • Phone Sign-inアプリ
    • Azure ADアカウントでサインイン
  • PC
    • Windows 10
    • Azure ADアカウントでサインイン
  • スマートフォンとPCがBluetoothでペアリングされていること


スマートフォンはこんな感じです。

Azure ADの組織に参加しています。

PCとBluetoothでペアリングされています。


PC側はこんな感じです。

Azure ADの組織に参加しています。

スマートフォンとペアリングされています。

◆動作

地味なので、動作は動画で公開してありますので、こちらを見てください。

2016年3月25日金曜日

[告知:de:code 2016]チョークトーク登壇&Vittorio本の翻訳出版のお知らせ

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

ご存知の通り5月24日~25日にプリンスパークタワー東京で開催されるde:code 2016ですが、チョークトーク・セッションに登場する機会を頂きました。

内容はまだこれからですが、お題は「認証とか認可でもやもやしている方のための公開相談室」ということで、おなじみのMS安納さん、松崎さん、ゆりか先生こと村木さんと私の4人で濃い話をすることになりそうです。
https://www.microsoft.com/ja-jp/events/decode/2016/special.aspx#CHK-003

[紹介文より]
ユーザー管理や認証、そして認可を正しく理解するには、膨大な量の読書と長い経験が必要です。でも、なかなかそんな時間が取れないのが実情。本セッションは、皆様がお持ちの疑問に対して、テクニカル エバンジェリストに加え、セキュリティ サポート担当、そして現場でいやというほどアイデンティティ関連案件を担当している Microsoft MVP が経験と知識をフルに動員して、我先に回答するチョーク トークです。

※写真はComing Soonとういことで(笑)


また、先日のActive Directory & Security Conference 2016に参加された方にはPreview版が配布されたおなじみVittorio Bertocciの新刊「Modern Authentication with Azure Active Directory for Web Applications」の日本語版をde:code 2016に合わせて発売する予定です。

Active Directory & Security Conference 2016で配布されたPreview版


しばらく先の話ではありますが、是非ご参加ください。

2016年3月22日火曜日

Active Directory & Security Conference 2016の資料・デモの公開

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

先日(3/18)のActive Directory & Security Conference 2016はイベント公開後すぐに満席になってしまうほどの盛況ぶりで、当日も日本マイクロソフトのセミナルームに人があふれている状態という異常な盛り上がり状況でした。

私はDeep Diveトラックということで濃いトラックを担当していましたので、先日のポストで予告させていただいた通り、Azure ADのアプリケーション連携の機能について紹介させていただきました。

動画の撮影もしていたようなので、いずれChannel 9などで公開されることになるとは思いますが、取り急ぎ資料の公開をしておきます。


尚、SAMLを使ったID連携のデモとして①Google Appsおよび②カスタムアプリ(simplesamlphp)、OpenID Connectを使ったデモとして③カスタムアプリ(php)と④API(graphおよびuserInfo)を直接たたくデモを用意していましたが、当日は②のsimplesamlphpおよび④のAPI実行のデモしかやっていませんので、他のモノを含め改めて動画公開をしていこうと思います。

取り急ぎは、以前から公開しているものとして、①を。


3/24追記)こちらは②のsimpleSAMLphpとAzure ADのSSOです。

残りは準備している最中なので、でき次第Channel 9で公開していきたいと思います。

2016年3月14日月曜日

[MIM]Microsoft Identity Manager March 2016 Previewが公開

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

マイクロソフトの製品開発がサイクリックに細かいアップデートを出していく、という方法にかわり、Microsoft Identity Manager 2016(MIM)についても例外なく小さなアップデートがちょいちょい出てくる、という形になってきているようです。

今回はMarch 2016 CTPということでconnectサイトに登録してダウンロードするという形で提供されており、以下のシナリオが用意されています。

https://connect.microsoft.com/site433/Downloads/DownloadDetails.aspx?DownloadID=57668

1. MIM Portal end-user self-service from additional browsers
 FirefoxやChromeでMIMポータル・セルフサービス機能へアクセスする
2. PAM with activation into groups in the “PRIV” forest
 すでに特権フォレストに存在するユーザとグループをPAMロールに含める

時間作って触ってみないと。。

2016年3月13日日曜日

[Windows 10]Microsoft Passport for Work 2Goが来たか?

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

Windows 10のデバイスへのサインイン方法は従来のID/パスワードに加えてPINやWindows Helloの生態認証など大幅に拡張されています。

また、追加でWindows 10 Mobileのスマートフォンを使ったサインイン方法が用意される予定で、ついにベータ版のアプリケーションがストアに登場しました。

が、結論まだまだマイクロソフト社内のテスト用に特化しているようで、まともに動きません。残念。

ということで、概要の紹介と試行錯誤の結果だけ書いておきます。


◆スマートフォンを使ったサインイン

機能の名称は「Microsoft Passport for Work 2Go」になるのかな?という気がしていますが、ようするに、Bluetoothで接続されたスマートフォン上で対象のコンピュータ名をタップすることによってサインインできる、という動きになります。

AndroidとChromebookにおけるSmart Lock for Chromebookと同じですね。
※Smart Lock for Chromebookに関する過去のポストはこちら


◆動作に必要な要件

まだ私の環境では動いていないので動作に必要な要件というのもナンセンスなのですが、色々と資料を見ていると、
・Windows 10 mobile(10.0.14283.1000以降?)のスマートフォン
・スマートフォンにはPhone Sign-inアプリがインストールされていること
・Azure ADに登録されたPC(つまりMicrosoft Passport for Workが動いている環境)
 ※必然的にTH2以降のWindows 10 Pro以上
・スマートフォンとPCがBluetoothでペアリングされていること
が条件になってきそうです。

◆現状の動き

とりあえず、どんな動きになるのか確認してみます。

<PC>
先の条件を満たしたPCにAzure ADのアカウントでサインインすると、サインイン画面にスマートフォンでサインインというメニューが出てきます。

これをクリックするとこんな画面が出てきます。


<スマートフォン>
本来はここでスマートフォン側のアプリ(Phone Sign-in)でコンピュータ名を選んでログインするんでしょうが、現状はアプリケーションにアカウントを追加するところでエラーが出て、うまく動きません。

とりあえずできているところまで紹介します。
①ストアからPhone Sign-inをインストールする
 現状ストアアプリで検索しても出てこないので以下のリンクから直接ストアへ移動してダウンロード・インストールを行います。
 https://www.microsoft.com/en-us/store/apps/phone-sign-in-beta/9nblggh5lb73

 ここで問題となるのが、最新のWindows 10 mobileのビルドが要求されてしまうところです。手元にあったWindows 10 mobileは10.0.10586.164だったのですが、このビルドではインストールできませんでした。


仕方がないので、Fast Ringより10.0.14283.1000へあげてみます。ちなみに現状このビルドへあげられるのはかなり限定されたデバイスだけみたいです。(手元のLumia 430はNG、Lumia 950はOKでした)


ビルドを上げた後、再度ストアへアクセスすると今度はちゃんとインストールできました。


②アプリにアカウントを登録する
どうやらサインインに使うアカウントをアプリにも登録しておくようです。
断定できないのは、ここでエラーが発生して先に進めていないからです。。。



まずは、スマートフォン自体にサインインしているアカウント(Azure ADアカウントでサインインしています)が表示されるので、選択してみます。

選択して先に進むと、エラーがでてしまいます。


こうなるとにっちもさっちもいきません。
アプリを再起動してもこの状態のままで何もできなくなります。
仕方がないので、アプリを削除して再インストールします。

今度は別のアカウント(スマートフォンへログインしているユーザではないAzure ADユーザ)を追加してみます。
すると、別のエラーが出ます。

Azure ADにセットされているReply URLがCloud eXperience Hostと同じくAAD Broker Pluginとなっており、Azure ADテナントに登録されているアプリケーションのReply URLと異なっているようです。このあたりからまだまだインターナル用なのかな?という推測をしています。おそらくインターナルテスト用のAzure ADにはこの仕組みに対応したアプリケーションが登録されていて、うまく動くんだと思います。



とりあえず今後の更新に期待ですね。
アプリの解説ページにも今後はマイクロソフトアカウントでも使えるような拡張なども予定されているようですし。





2016年3月12日土曜日

[翻訳]Azure ADとWindows 10におけるMicrosoft Passport for Work

こんにちは、富士榮です。
Windows 10におけるFIDO/Microsoft PassportWindows Helloについて本ブログでもお伝えしてきましたが、今回はマイクロソフトでWindows 10とMicrosoft Passportを中心に担当しているJairo Cadena氏のAzure ADとWindows 10のMicrosoft Passport for Workの動作の裏側に関する記事の翻訳をお送りします。(翻訳版の転載を快諾していただいたJairoさんに感謝!)
それではどうぞ。
***************************
Windows 10デバイスを利用する際の利点の一つは、Azure ADに登録されたWindows 10のデバイスは、Windows HelloとMicrosoft Passport for Workにより実現する利便性とセキュリティです。このポストでは、Azure ADと連携するMicrosoft Passport for Workのテクノロジについて、およびそれがどのようにデバイスと強固な認証と関連するのかを掘り下げていきます
Microsoft Passport for Workはアプリケーションの認証のため、3種類のAzure ADへのデバイス登録方法のすべてでサポートされます。 このポストでは主にAzure ADへ参加したデバイスと、ドメイン参加したデバイスに焦点を当てます。
パーソナルデバイスに関する簡単なメモ
2015年11月の更新プログラムを適用したWindowsのパーソナルデバイスの場合、Microsoft Passport for Workは、ユーザに関連づけられたジェスチャー(詳細については今後のポストで紹介します)によるクレデンシャルのアンロックによる従来のアプリケーション(VPNなど)のための証明書の保護については限定的です。 これらの証明書は一般的にモバイルデバイス管理(MDM)システムによって配備されます。
Microsoft Passport for Workは、MDMがAzure ADに対して自動登録設定が行われていない限り、職場または学校のアカウントの追加を行っても表示されてきません。この場合、このデバイスを利用しているユーザーは、Microsoft Passport for Workを使用して、Azure ADで認証されません。これは将来のWindowsのアップデートにより、サポートされる予定です。
一方、(個人的なデバイスを含む)Windows 10のデバイスが持つクレデンシャルは、Azure AD参加もしくはドメイン参加したデバイスへのリモート認証するために利用できます。詳細については今後のポスト、Microsoft Passport for Work 2Go:携帯電話を利用してWindowsへの認証を行うをご覧ください。
パスワードの現状
今日、パスワードには問題があります。それらは複製しやすく簡単に盗むことが出来ます。それら実装における問題は、パスワードを安全ではないものとし、ユーザーは利便性とセキュリティのバランスをとるのに苦労しています。しばしばユーザーはセキュリティ要件が求められた際、簡単に利用するための「回避策」を見つけてしまいます。(例えば、複雑なパスワードが求められる場合、それを保護されていない場所に書いてしまうこともあります)
Microsoft Passport for Workは、ユーザーのジェスチャー(PINもしくは指紋や顔認識などの生体ジェスチャー、すなわちWindows Hello)によって保護された、デバイスに強固に紐づけられたユーザーの資格情報を使用してユーザーのパスワードを置き換えます。
パスワードの問題の詳細については、最近TechNetで公開されたMicrosoft Passport guide 伝統的な資格情報の問題の章を参照してください
Microsoft Passport for Workの資格情報
資格情報は、デバイスのトラステッドプラットフォームモジュール(TPM)にセキュアに保存された秘密鍵、およびAzure AD上に安全に登録された対応した公開鍵の構成される非対称鍵(秘密鍵と公開鍵のペア)です。 TPMが存在しない場合、キーはソフトウェア的に生成され、暗号化されて保存されています。
秘密鍵は、安全な場所を出ることはなく(TPMが利用可能な場合)、Azure ADまたはADに知られることも、ネットワークを流れることもありません。 それは、"Hello"を使って暗号化・保護され、ユーザーが知っていること(PIN)もしくはユーザーが誰であるか(バイオメトリクス)によってのみアクセスが可能です。”Hello”はジェスチャー、デバイスとユーザー毎に固有な認証器なのです。
公開鍵は、デバイスとユーザーの両方の認証が完了した後にAzure ADに安全に登録されます。ユーザーは第2の要素を提供することで、強固に認証される必要があります。Microsoft PassportはAzure ADで認証する際、強力な資格情報と見なされるため、これは重要なことです。資格情報が多要素認証(MFA)ポリシーを満たし、この資格情報で取得されたトークンは、対応する関連属性を含みます。
資格情報がプロビジョニングされると、それはAzure ADでの認証のために使用されます。
Microsoft Passport for Workの資格情報のプロビジョニング
すべては、デバイスがAzure ADに登録されるところから始まります。デバイスはMicrosoft Passport for Workの資格情報を取得する前に、Azure ADへ参加、もしくはドメインへ参加(することによるAzure ADへ自動登録 )、職場または学校のアカウントを追加している必要があります。
Azure ADへ参加もしくはドメイン参加したデバイスの登録が完了した後、次回にユーザーがWindowsへサインインする際、Microsoft Passport for Workのプロビジョニング画面が表示されます。Azure ADへの公開鍵の登録は、Azure Device Registration Service(Azure DRS)によって行われます。
これはシステム内の特定のWinRT APIへアクセス可能なホストである、Cloud eXperience Host(CXH)内にレンダリングされるWebドリブンの画面です。これはAzure AD参加の際に使用されているもののと同じホストです
以下の条件に該当する場合 、Windowsにユーザーがサインインした後に起動されます:
  1. Microsoft Password for Workのポリシーがプロビジョニングされている。これは次の条件のいずれかを意味します:
    • デバイスがAzure ADに参加しており、Microsoft Passport for Workのポリシーが無効になっていない (ポリシーが存在しない場合のデフォルトの動作では、資格情報をプロビジョニングします)。
    • デバイスがドメイン参加しておりポリシーが有効になっている(ポリシーが存在しない場合のデフォルトの動作では、資格情報のプロビジョニングを行いません)。これは、ドメイン参加したデバイスが資格情報を使用してドメインコントローラ(DC)で認証できるようにオンプレミスのインフラストラクチャに必要な準備を行うためです。必要な設定が行われた後、組織はポリシーを有効にすることができます。記事の後半でオンプレミスADの認証のサポートに関するいくつかの考慮事項について言及します。
  2. 現在のセッションがリモートセッションでないこと。これはMicrosoft Passport for Workのプロビジョニングが仮想マシン(VM)上で発生しないことを意味しているわけではありません。しかし、ユーザーがリモートデスクトップサービスセッション(RDS)経由でVMまたは物理デバイスに接続している場合、プロビジョニング画面は表示されません(これはHyper-Vの拡張セッションモードでの接続を含みますので、検証環境で試す場合はHyper-Vホスト上で行う必要があります)。
上記の条件が満たされると、プロビジョニング画面が表示されます。これは次の場所でホストされています:
  https://account.live.com/aadngc
次のページが表示されます。
ブログ -  PINを設定します
ユーザーが「PINを作成」ボタンをクリックするとdsreg.dllのWinRTのAPIの部分が呼び出されます。この登録APIは、次の2つの操作を実行します:1)Azure DRSでトークンを取得するために現在のユーザーを認証する、2)鍵ペアを生成し、(1)で得られたトークンを使用してAzure DRSへ公開鍵を登録する。
(1) Azure DRSでのユーザー認証
まず初めに登録APIは、次に生成される公開鍵をAzure ADに登録するためのアクセストークンを取得します。このトークンは、Azure DRSが対応するユーザーに公開鍵を登録し、対応するデバイスオブジェクトと関連づけるために利用されます。トークンを取得するため、登録APIはWebアカウント・マネージャのAPIを使用します。
  Windows.Security.Authentication.Web.Core.RequestTokenForWindowAsync 
このAPIは、Azure ADプラグインの対応する実装を呼び出します。ウェブアカウントマネージャーとAzure ADプラグインの詳細については今後の記事、Windows 10においてSSOはどのように動作するのかを参照してください。
いくつかの条件に応じてユーザーにはMFAが要求されます。
  1. ドメイン参加デバイス上のユーザーはMFAが要求されます。これはユーザー名とパスワードの資格情報を使用しています。Windows 10の2015年11月の更新では物理または仮想スマートカードを使用してWindowsにログインしている場合、Microsoft Passport for Workはサポートされませんので注意してください。これはWindowsの将来のアップデートで対応されます。
  2. Azure AD参加デバイス上のユーザーは、そのユーザーが最初にこのデバイスをAzure ADへ参加させたユーザで、デバイス参加時に多要素認証されている場合、MFAを要求されません(デバイスオブジェクトの属性「RegisteredOwners」にこのユーザーが設定されます)。Azure ADはデバイス登録時に多要素認証が行われた場合、そのデバイスを認証の第2要素として扱います。この動作はこの記事が書かれた時点のサービスの動作であることに注意してください。私たちは、登録されたデバイスを多要素としてに扱うことに関する複数のフィードバックを受けとっています。将来的には、組織が制御することができる設項目定の中で設定できるようにする予定です。
  3. Azure AD参加デバイス上のユーザーで、デバイスをAzure ADへ参加させたユーザーではない場合はMFAが要求されます。
フェデレーションを行っている組織の場合、MFAはAzure ADもしくは組織内のSTS(例えばAD FS)から要求することが出来ます。
ブログ -  NGCプロビジョニング時にMFA
ユーザーが認証され、APIがトークンを取得した後、Microsoft Passport for Workの鍵の生成と登録プロセスへ進みます。
(2) Microsoft Passport for Workの鍵の生成とAzure ADへの登録
登録APIは、鍵を生成し利用可能な場合はAttestationデータを取得するには、Microsoft Passportの暗号API(ncrypt.dllの一部)に依存しています。現状のクライアントとサービスの実装ではまだAttestationの検証をサポートしていませんのでご注意ください。サービスおよび/またはWindowsの将来のアップデートでこの機能が有効になります。
一般的に鍵はこの瞬間に作成されるのではなく、事前に生成された鍵のプールから取得されます。複数の鍵の事前生成は、デバイスの起動時にバックグラウンドで実行されます。RSA 2048ビットの鍵ペアの生成はTPMに依存し、生成するのに少し時間がかかります
鍵ペアが得られた後、PIN設定のためのUIが表示され、ユーザはPINを要求され​​ます。論理コンテナが作成され、秘密鍵はその中に配置されます:
ブログ -  NGC PINコレクションのUI
コンテナは、ジェスチャに関連付けられている保護鍵で保護されている鍵情報の論理的なグループです。この場合、PINはこのとき得られた保護鍵に関連付けられます。この鍵は、取得したMicrosoft Passport for Workの秘密鍵を安全にラップします。PINのジェスチャーは、論理コンテナを開き秘密鍵へアクセスするためのものです。
鍵のAttestationについて
前述したように、Attestationの検証はまだ実装されていませんが、ここでAttestationの生成の背後にあるメカニズムのいくつかの詳細を解説します。対応する公開鍵と共に、利用可能な場合は関連するAttestationデータも、暗号化APIを使用して取得されます。AttestationデータはAttestation Identity Key(AIK)証明書とユーザーと生成されたMicrosoft Passport for Workキーに関する情報を保持しているBlobで構成されています。Blobは、TPMがプラットフォームの認証を提供することを可能にする特別な目的のRSA鍵であるAIKによって署名されています。Endorsement Key(EK)および(製造者からの)証明書と併せてAIKは、TPM製造者と信頼のチェーンを持つAIK証明書を生成するために、Azure証明書サービスへ送信されます。この信頼チェーンは、サービスがキー登録時に検証するためのものです。
登録APIは、Azure DRSのアクセストークンと鍵情報を取得し、Azure DRSの次のエンドポイントにPOSTします。
  POST http://enterpriseregistration.windows.net/EnrollmentService/Key 
Azure DRSはディレクトリ内のユーザーオブジェクトを検索し、特定のマルチバリュー属性に鍵情報を追加します。 鍵情報にはデバイスIDへの参照が含まれています(ユーザとデバイスIDの両方がトークンから取得されます) ユーザオブジェクトは、Microsoft Passport for Workの資格情報をプロビジョニングしたそれぞれのデバイスに対して1つのキーを持ちます。
Azureの管理ポータル内のユーザーのデバイスのUIについて
もう一つ興味深い点を。Azureの管理ポータル内のUIにはユーザーが自身が(Azure AD参加もしくは職場または学校のアカウントを追加によって)登録したデバイスの情報が表示されます。ドメイン参加したWindows 10デバイスは、Azure ADへのデバイス登録プロセスにユーザーが参加しないため、管理ポータルのUIには表示されません。例外として、ユーザーがMicrosoft Passport for Workの資格情報をプロビジョニングすると管理UIのユーザーのデバイスの下にドメイン参加したデバイスが表示されます。
Microsoft Passport for Workの資格情報を使用した認証
最終的に資格情報がプロビジョニングされた後、その資格情報をAzure ADでの認証時、およびオンプレミスのADでのWindowsへのサインイン時に利用することが出来ます。どのようにこれが行われるのかの詳細については将来の記事、Windows 10においてSSOはどのように動作するのかを参照してください。
オンプレミスのADへの認証
オンプレミスADに対するMicrosoft Passport for Workをサポートするには、デバイスがWindows Server 2016(この記事の執筆時点では、テクニカル・プレビュー4です)で動作しているDCに到達できるようにする必要があります。 オンプレミスADは新しいドメインまたはフォレストの機能レベルで構成する必要はありません。
新しいDCを展開する代わりに、Microsoft Passport for Workで使用されるログオン証明書を展開することもできます。 この場合、下位バージョンのDCでは認証に証明書(今日と同様に仮想スマートカード)を利用し、ユーザーはWindows Helloのメリットを享受できます。この場合においてもAzure ADは認証に鍵を使用していきますのでご注意ください。
Microsoft Passport for Workの鍵を使うログイン証明書をサポートするためには、System Center Configuration Manager Technical Preview(ドメイン参加したデバイス用)またはIntune(Azure AD参加したデバイス用)が必要です(サードパーティのMDMも同様にサポートされるようになります)。
オンプレミスのADへの認証を有効にする場合の展開の要件の詳細についてはTechnetのMicrosoft Passport guide展開の 要件セクションを参照してください。また、より多くのリソースを参照するには関連するTechNetドキュメント(ここ)を参照してください。
最後に、ここまで読んでいただき、これらの機能に興味を持っていただいたことに感謝します。質問やコメントがあればお聞かせください。
ではまた次回。
Jairo Cadena(Twitter:@JairoC_AzureAD)
***************************

他にもJairoさんの記事には興味深いものが多数あるので、また翻訳をしてみなさんに公開していきたいと思います。

2016年3月10日木曜日

[小ネタ]Azure ADからGoogle Appsへのプロビジョニング

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

今回は小ネタです。しかも事象からの推測ですのでタダの都市伝説かもしれません。

ご存知のとおり、Azure Active Directory(Azure AD)が持つアプリケーション連携の機能には「シングルサインオン」と「プロビジョニング(ID同期)」の2つがあります。

で、今回はプロビジョニングに関する小ネタです。
※プロビジョニングの細かい設定方法は以下の動画をどうぞ。(IdM実験室別館より)
 https://channel9.msdn.com/Blogs/IdM-Lab-Annex-MVP-for-Directory-Services-Naohiro-Fujie/AAD-Setup-App-3

Google Appsへユーザを新規にプロビジョニングした場合、作成されたユーザのステータスが「無効」になっている場合と「アクティブ」になっている場合があります。

<そもそものGoogle Appsの仕様は?>

Google Admin SDK Directory APIの仕様を見ると、新規に作成されたユーザはサスペンドされ(suspendedにtrueがセットされ)、サスペンド理由(suspensionReason)にWEB_LOGIN_REQUIREDがセットされ、初回ログイン時にアクティベートされる、と書いてあります。
https://developers.google.com/admin-sdk/directory/v1/reference/users
抜粋)
A new account is automatically suspended by Google until the initial administrator login which activates the account. After the account is activated, the account is no longer suspended

しかし、先に書いた通りAzure ADからユーザをプロビジョニングすると最初からsuspendedがfalseのユーザ(アクティブ)ができる場合と、仕様通りtrueのユーザ(無効)の両パターンができる場合があります。

<Google Apps上のユーザの状態>

<有効なユーザ>

Directory APIでGoogle Appsを直接見ると、suspendedがfalseになっています。

この状態でログインすると、規約への同意をすればすぐにサービスが使えます。



<無効なユーザ>

同様にAPIを直接たたくとsuspendedがtrue、suspensionReasonがWEB_LOGIN_REQUIREDとなっています。APIドキュメント通りです。

この状態だと、ログイン時に本人確認が走ります。



<Azure AD上でのアカウント状態の違い>

何が違うのか?を追うためにAzure AD上でのユーザの違いを眺めると、、、

最初からアクティブになるユーザ:オンプレミスのADから同期されてきたユーザ
無効となるユーザ:Azure AD上に直接作ったユーザ

という違いがありました。
本当にこれが原因なのかどうかはよくわかりませんが、少なくとも私のテナントではこの部分しかアカウントの違いがなく、何ユーザ試してみてもこの動きになったので、何か関係しているのかもしれません。

マイクロソフトやGoogleに確認した訳ではないので、厳密には良くわかりませんが。。。





2016年3月7日月曜日

[SAML/OpenID Connect]どうなる?Microsoft Passportを使った場合のacr/amr

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

SAMLやOpenID ConnectではIdentity Provider(IdP)でユーザがどのような方法で認証されたのかをAssertionやid_tokenの中に含めてRelying Party(RP)へ連携を行います。

この目的は、RPがIdPから渡される認証手段を検査して、求めるLoA(Level of Assurance/保証レベル)を満たしているかどうかを判断し、ログインを許可するかどうかを判断させることにあります。例えば、決済に関するサービスであればパスワードを使った認証では不十分で多要素認証を求める、などの判断を行います。

では、Azure ADに参加したWindows 10のPCにログオンし、Microsoft Passportを使ってアプリケーションへシングルサインオンした場合、IdPであるAzure ADはRP(アプリケーション)へどのような値を連携するのでしょうか?Microsoft Passportを使うということは、Azure ADへのログオン時に一切パスワードを使っていません。
(ついでに言うと今回のテスト時、PCへのログオンはWindows Helloを使ったので、PCへのログオン時にもパスワードは一切使っていません)

早速見てみましょう。
今回は、SAMLおよびOpenID Connectに対応したアプリケーションを用意し、fiddlerで実際にどのような値が渡ったのかを覗いてみます。

◆SAMLとOpenID Connectにおける認証手段の表現方法

まずSAMLとOpenID Connectにおける認証手段の表現方法を確認しておきましょう。

  • SAML
    • AuthnContextのAuthnContextClassRef属性を利用します。例えば、パスワードで認証されたことを示す場合は、[urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport]がセットされたり、AD FSなどを使って統合Windows認証が使われた場合は[urn:federation:authentication:windows]が使われたりします。
  • OpenID Connect
    • (2016/03/07追記)SAMLと同じくacr(Authentication Context Class References)を使います。OpenID Connectにおいてはid_tokenの中に値が設定されます。が、現状Azure ADにおいてはacrはセットされないようです。(B2Cテナントにおいては何故か固定値[b2c_1_sign_in]がセットされます)
    • id_tokenの中のamr(Authentication Methods References)クレームを利用します。どのような値が使われるかはプロトコルの規定外ですが、パスワードで認証された場合は[pwd]が使われたりします。



◆SAML対応アプリケーションへ渡されるAssertionを覗いてみる

では、早速SAML対応のアプリケーションへログオンしてみます。
Azure ADに参加したWindows 10のPCへAzure ADユーザでログオンし、アクセスパネル(https://myapps.microsoft.com)をMicrosoft Passportに対応したブラウザ(今回はEdgeを使いました)でアクセスします。


Microsoft Passportが有効なので、パスワードを入力することなくアクセスパネルが開きますので、SAMLに対応したアプリケーション(今回はGoogle Appsを使います)を開いてみます。

このとき、fiddlerを立ち上げて通信をキャプチャしておき、Google AppsのAssertion Consumer Service(www.google.com/a/ドメイン名/acs)へPOSTされるSAMLResponseを拾います。


拾ったSAMLResponseはSAML AssertionをBase64URL Encodeしたものなので、Decodeしてから目的のAuthnContextClassRefを探します。
ちなみに、SAML2 debuggerというサイトを使うとSAMLのメッセージをEncode/Decodeできるので便利です。
 参考)SAML2 Debugger
   https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php



結果、[urn:oasis:names:tc:SAML:2.0:ac:classes:Password]が入っています。
パスワードで認証したわけではないのに、パスワードで認証されたことになっている、ということです。
Azure ADを使ってSAMLアプリケーションにログインする場合は、どんな認証手段を使ったかについてはあてにならない、ということですね。


◆OpenID Connectアプリケーションへ渡されるid_tokenを覗いてみる

次は、OpenID Connectです。
SAMLの場合と同じく、Azure ADと連携したアプリケーションへMicrosoft Passportが有効な環境でログオンしてみます。

id_tokenをアプリケーションへ渡す方法(response_mode)も色々ありますが、今回のアプリケーション(自作)ではAzure ADの初期値であるform_postでid_tokenを渡しているので、Azure ADでログオンを行うとformを含むhtmlがダウンロードされ、JavaScriptで自動的にformデータがPOSTされます。
fiddlerで見ると、こんな感じに見えます。


このid_tokenの中身を覗いてみます。今度はJSON Web Token(JWT)なので、decodeするとPayload部分のJSONに各種クレーム(属性)が出てきます。

SAMLではSAML2 Debuggerを使いましたが、OpenID Connectの場合はjwt debuggerを使います。
 参考)jwt debugger
   http://jwt.io/

こんな感じで出力されます。

amrクレームの値を見ると、[pwd]と[rsa]の2つの値が入っています。
SAMLの場合と異なり、一応署名検証を使った認証を使ったことも認識されているようです。
(実際には使っていないパスワードも使ったことになっていますが)


ちなみに、Microsoft Passportが無効な環境で同じアプリケーションにアクセスした場合は[pwd]のみしかamrクレームに入ってきませんので、一応認証方式が異なることを表現してはいるようです。

こちらが、Microsoft Passportなしでログインした場合のamrの値です。



◆結論?

現段階において、Azure ADと連携するアプリケーションを開発する場合は、SAMLにおけるAuthnContextClassRefやOpenID Connectにおけるamrを見て認証方式や強度を判断するのは困難なようです。(OpenID Connectの方が若干マシですが、pwdが残ってるのは?です)


いずれにしても、想定している認証手段でログオン~ID連携が行われた場合にアプリケーションがどのような値を受け取るのか?についてはテスト段階で十分に検証を行っておく必要がありますね。