IdM実験室: 5月 2015

2015年5月30日土曜日

[FIDO/Windows10]idcon vol.20（別名fidcon）が開催されました

先日のポストで紹介させていただいた通り、Identity Conference / idcon の記念すべき20回目が開催され、私も Windows 10 の FIDO（First IDentity Online）実装である Microsoft Passport および Windows Hello について話をさせていただきました。

参考）
　Identity Conferenceのページ
　https://idcon.doorkeeper.jp/events/23320

　FIDO Allianceのページ
　https://fidoalliance.org/

◆当日の流れと様子
詳しくは @nov さんが togetter にまとめてくれていますが、当日は以下の順番で講演が行われました。

1. Token Binding と FIDO / レピダム前田さん（@mad_p）

Tokbind-fido from Kaoru Maeda

OAuth の Token や Cookie などの Bearer Token はその名の通り、Bearer（持って来た人が使えてしまう）なトークンなので、認証等のセキュリティが求められるトランザクションには不向きです。Token Binding は Token を行使できる相手の ID と Token を関連付けて管理していこう、という取組みです。今回前田さんに紹介いただいたのは tls-unique を使って TLS セッションと Token を関連付け、TLS セッションが生きている間は Token を有効にする、という仕組みでした。
また、この Token Binding を安全にやり取りする仕組みとして、id_token 内に入れて署名する方法や、今回のテーマでもある FIDO を使って署名する方法が紹介されました。

2. FIDO in Windows 10 / ふじえ（@phr_eidentity）

FIDO in Windows10 from Naohiro Fujie

2番目が私のパートでした。
基本的にはこれまで本ブログで書いてきたことばかりではありますが、マイクロソフトが Windows 10 と Microsoft Azure Active Directory で目指している True SSO 環境＝「どこからでも、どんなデバイスからでも、デバイス～アプリケーション間での SSO を実現できる環境」と構成する要素である Microsoft Passport / Windows Hello の概要の説明、そして Azure AD Join を行った環境におけるデバイス登録～ログイン～アプリケーション利用までのフローの解説をさせてもらいました。
FIDO との関係としては、デバイスの登録およびPCへのログインの部分の仕組みが正に FIDO、そのあとのアプリケーション利用の仕組みは OpenID Connect ってあたりです。

3. Yahoo! JAPAN の FIDO への取り組み / ヤフー五味さん

Idcon gomi-052715-pub from Hidehito Gomi

このセッションが一番最初だったら良かったんじゃ、、と思いました。
パスワードの課題～ FIDO の概要・仕組みに関する説明が抜群にわかりやすかったので、このスライドを見た後に、Azure AD Join のフローを見るとどこが FIDO なのか？についてより理解できると思いました。
FIDO の本質はデバイス登録～信頼により、認証サーバが登録済みデバイスによって行われたユーザ認証結果を信頼する、という流れでユーザ認証に関するやり取りがネットワーク上を流れなくする＝クレデンシャルを保護しやすくなる、というのが一番のキモですね。

4. パスワードレス認証 M-Pin の概要 / CertiVox 尾崎さん

NTTソフトさんの Trust Bind との組み合わせソリューションとして最近日本でも活動を始めた英国の CertiVox 社のパスワードレス認証の仕組み「M-Pin」の紹介でした。
FIDO のような標準化を目指した仕組みではなく、独自の仕組みではありましたが、銀行 ATM の暗証番号入力のようなユーザ・インターフェイスは使いやすそうで、一般の利用者に多要素認証を使わせるにはハードルが低いのではないか？と思いました。

https://www.certivox.com/

◆おまけ
ちなみに、セッションを引き受けた時は Windows Hello が5月末には使えるようになっているだろうなぁ、、、という微かな期待の元、インテルの Real Sense （3D/赤外線カメラ）を買って準備していたんですが、残念ながらセッション当時リリースされていた Windows 10 Technical Preview Build 10074 / 10122 ではまだ Windows Hello は実装されていませんでした・・・。昨日あたらしく 10130 がリリースされていたので、そちらで試してみてまた別途レポートします。。

製品ページ
　http://www.intel.co.jp/content/www/jp/ja/architecture-and-technology/realsense-overview.html
Amazon
　http://amzn.to/1LPbBbW

2015年5月20日水曜日

[FIM/MIM]CTP4へのインプレースアップデート（Sync Engine編）

4月下旬にconnectサイトにリリースされたMicrosoft Identity Manager 2016 CTP4ですが、今回のバージョンからインプレース・アップデートに対応しています。
※現状FIM CMについてはバグがありアップデート出来ないようですが。

参考）
　[MIM]新しいPublic Previewがリリース、MIM2016へ
　http://idmlab.eidentity.jp/2015/04/mimpublic-previewmim2016.html

今回はSynchronization Serviceのインプレース・アップデートを行ってみます。

◆結果
今のところ何の問題もなく、HotFixを適用するのと同じ程度の手間でアップデートが出来ました。
（特にSyncエンジンは殆ど何も変わっていないので、当たり前ですが）
また、ECMA2で作成したGeneric REST MAについても簡単な確認をした限りでは問題なく使えていそうです。

◆アップデート手順
まず、アップデート前のバージョンを確認しておきます。

2つ前のHotFixが適用されたForefront Identity Manager 2010 R2 SP1（FIM2010R2）ですね。

早速connectからダウンロードしたCTP4を解凍し、Synchronization Serivceフォルダ以下のsetup.exeを実行します。

ちゃんとUpdateとして認識してくれているようです。

まだ、バージョン番号がMicrosoft Identity Manager 2015のままですね。

アップデートなので基本的な設定は引き継いでくれます。

色々と注意事項がでますがセットアップを継続です。

セットアップはすぐに終ります。
特に問題なくセットアップフェーズは進みました。

◆確認
早速Synchronization Managerを起動します。

起動時のロゴがMicrosoft Identity Managerになっていますね。

しかし、バージョン情報を見ると相変わらずFIMのままです。
ビルド番号は流石に4.1.1790.0と新しくなっていますが。

この状態で簡単に管理エージェントを動かしてみましたが、特に問題なく動きました。

ここまでです。Synchronization Serviceについては何の問題もありませんでした。

次回はFIM Servive/Portalのアップデートをやってみまたいと思います。
（こちらはそれなりに変な動きをしてくれています。流石にモジュール構成の変更が多いので難しい部分だったのだと思います）

2015年5月12日火曜日

[Build 2015]アイデンティティ関連セッションリスト

4月～6月にかけて海外では各種イベントが続々と開催され、アイデンティティに関しても新しい情報が出てきたりするので目が離せません。

・Microsoft
　Build 2015
　http://www.buildwindows.com/

　Ignite 2015
　http://ignite.microsoft.com/

・Kuppinger Cole
　Europian Identity & Cloud Conference 2015(EIC 2015)
　https://www.id-conf.com/

・Ping Identity
　Cloud Identity Summit 2015
　http://www.cloudidentitysummit.com/

今回は先日サンフランシスコで開催されたMicrosoftのBuild 2015よりアイデンティティ関連のセッションをピックアップしました。
スライドとビデオが公開されているので、Azure Active Directory（AzureAD）、Office365 API、Windows 10のPassport/Windows Hello関連に興味のある方は必見です。

◆AzureAD連携アプリケーション開発関連
Azure Active Directory: Identity Management as a Service for Modern Applications
http://channel9.msdn.com/Events/Build/2015/2-738

Cloud Authentication Troubleshooting and Recipes for Developers
http://channel9.msdn.com/Events/Build/2015/2-740

Develop Modern Web Applications with Azure Active Directory
http://channel9.msdn.com/Events/Build/2015/2-753

Develop Modern Native Applications with Azure Active Directory
http://channel9.msdn.com/Events/Build/2015/2-769

◆AzureADとOffice365 API関連
Get Your Hands Dirty with the Office 365 APIs, Authentication and SDKs
http://channel9.msdn.com/Events/Build/2015/4-630

◆Passport/Windows Hello関連
Single Sign-On with Secure Authentication
http://channel9.msdn.com/Events/Build/2015/2-709

Managing Mobile Devices and Applications in an Enterprise
http://channel9.msdn.com/Events/Build/2015/3-654

Microsoft Passport and Windows Hello: Moving Beyond Passwords and Credential Theft
http://channel9.msdn.com/Events/Build/2015/2-639

Building Universal Windows Apps with Office 365 APIs
http://channel9.msdn.com/Events/Build/2015/3-767

App-to-App Communication: Building a Web of Apps
http://channel9.msdn.com/Events/Build/2015/3-765

尚、セッションデータを一括ダウンロードするスクリプトが公開されているので、上手く活用をして効率的にマテリアルをダウンロードすると良いでしょう。
https://gallery.technet.microsoft.com/All-Videos-and-Slides-from-64a86489

ちなみにこのスクリプト（というよりもChannel9のRSSフィード）には不具合があり、一部修正が必要です。

以下のステップで修正をします。
１．RSSフィードを直接ダウンロードする
　　以下のURLをブラウザで直接開いて表示された内容を保存します。
　　http://channel9.msdn.com/Events/Build/2015/RSS/slides

２．ダウンロードしたフィードを修正する
　　1287行目のitunes:summaryの行に不具合があるので、この行を丸ごと消してしまいましょう。

３．スクリプトがローカルにダウンロード・修正したRSSフィードを読み込むように修正する
　　ダウンロードしたスクリプトがインターネット上のRSSフィードではなく、上記２で修正したフィードを読み込むように以下の様に修正します。
　　（修正前）

　　（修正後）

後は保存してPowerShellを実行すればごっそりファイルのダウンロードが出来ます。
※スライドだけでも1.7GBくらいあるので空き容量に注意が必要です。

2015年5月10日日曜日

[Windows10]デバイス＆サービス間のシングルサインオンの仕組み

※ご注意
・現在公開されている情報＋Fiddler等でWindows10の動きを解析した結果からの推測です。
　（そのうちMSDNあたりに確かな情報も公開されると思います）
・Windows10 Insider Preview（Build 10074）をベースに確認しています。
・細かい話は今月末（5/27）に開催されるidcon（別名fidcon）で話をする予定です。

今回はこれまで紹介してきたWindows10のクラウド・ドメイン参加（Cloud Domain Join/CDJ）によるPCログオンとOffice365等のアプリケーションの間のシングルサインオンの動作の仕組みについて考えてみます。

その前におさらいです。

◆CDJとは
簡単にいうと、Windows10のデバイス（PC）へのログオンにAzure Active Directory（AzureAD）を使う、つまりオンプレミスのActive Directoryへのドメイン参加ではなく、クラウド上のAzureADへドメイン参加する機能のことです。

＜関連ポスト＞
　[Windows10/AAD]クラウド・ドメイン参加を試す
　http://idmlab.eidentity.jp/2015/02/windows10aad.html

　[Windows10/AAD]OOBEでクラウド・ドメイン参加
　http://idmlab.eidentity.jp/2015/03/windows10aadoobe.html

◆CDJを使ったTrue SSOとは
これまでWebアプリケーション間のSSOはAD FSやAzureADなどSAMLやws-federationの実装により割と容易に実現出来ました。また、社内のPCの様にActive Directoryドメインに参加している環境においてはAD FSへの統合Windows認証をすることによりPCログオンとWebアプリケーションとの間でのSSOを実現してきました。
しかし、あくまで統合Windows認証に依存する仕組みのため、社外からのアクセスなどドメイン・ネットワークの境界を超えると途端にSSO出来なくなる、という非常に限定的な仕組みでもありました。

しかし、CDJを使いPCログオンをAzureADで行うことによりドメイン・ネットワークの境界の外にある社外PCについてもPCログオンとWebアプリケーションのSSOを実現することが出来るようになりました。

＜関連ポスト＞
　[Windows10/AAD]Technical Preview Build 10041のCDJでOffice365とのSSOを実現
　http://idmlab.eidentity.jp/2015/03/windows10aadtechnical-preview-build.html

　※ちなみにBuild 10074ではOffice365とのSSOは上手く動かず、代わりにAzureの新管理ポータル（https://portal.azure.com/）へSSO出来るようになっています。

さて、本題です。
では、CDJを使いWindows10のPCではどのようにデバイスとアプリケーションの間のSSOを実現しているのでしょうか？

CDJではざっくり言うと以下の処理が実行されます。
①AzureADへのデバイス登録
　⇒秘密鍵のダウンロード、TPMへの保存
②ユーザ認証
　⇒秘密鍵を使ってAzureADからプライマリ・リフレッシュ・トークン（PRT）の取得
③アプリケーションへのアクセス
　⇒AzureADでPRTをアクセス・トークンへ交換し、アプリケーションへ提示

PINや顔認証でPCにログインできるようになるのは、CDJでAzureADの信頼済みデバイスとして登録された後、TPM上にストアされた秘密鍵にアクセスすることが出来ることでユーザを認証することが可能なためです。
（この秘密鍵にアクセスするためのパスフレーズとしてPINやバイオメトリクスを使っているのが噂のWindows Helloです）

このあたりは、先日のJapan SharePoint Groupでデモを交えつつ話をした内容です。
当日のスライドはこちら。後半でNext Generation Credentials/NGC（現在はPassportって言ってるやつです）のフローを解説しています。

Microsoftの認証システムの歴史と過渡期におけるWAPの活用 +Next Generation Credentials from Naohiro Fujie

特にこの辺のスライドですね。

で、実際SSOを実現するには、この中で出てくるPRTをアプリケーション向けのアクセス・トークンに交換する必要がありますが、この部分を担当しているコンポーネントがWindows10から導入された「Web Account Manager」および「AAD Token Broker Plugin」です。

Web Account Managerは現在.NETやJava Script向けに提供されているActive Directory Authentication Library（ADAL）の後継（？）となるコンポーネントで、バックエンドで認証やアクセストークンの取得などの処理を行うものです。ただ、ADALが各アプリケーションに組み込むライブラリとして提供されていたのに対して、Web Account ManagerはWindows10/Windows Phone10に組み込まれた独立したモジュールとなっています。

OpenID ConnectのRPとして実装されたWebアプリケーションは、AzureAD上に登録する必要があり、登録の際のredirect_uriに「ms-appx-web://Microsoft.AAD.BrokerPlugIn/[アプリケーションのsid]」を指定することでWeb Account Managerを呼び出すことが出来ます。（ネイティブアプリケーションからはRequestTokenAsyncなどのAPI経由で呼び出します）

Build 2015のセッションより

単純にWeb Account Managerを使うだけだとAzureADで個別に認証をしてアクセス・トークンを受け取る必要がありますが、先にCDJで取得したPRTがあると、AAD Token Broker PluginがPRTをAzureADへ渡してアクセス・トークンを取得するのだと思われます。

これで、PCへのログオンとWebアプリケーションへのログオンのSSOの出来上がりとなります。

ちなみにAzureAD上にリソースとして登録していないWebサイトからの認証要求が来ると、AADのイベントログにID1098、1097が記録されるので、PRTの交換に失敗していることがわかります。

一番上にも書きましたが、5/27のidconでもう少し深く仕組みの紹介をしたいと思います。
※CDJの各フェーズで実際にどのような通信が発生しているのかをfiddlerで可能な限り取得した結果などもお見せできれば、、と思います。仕組み上、ログイン中に発生している通信も多いので、全部がトレースできる訳ではありませんが。。。

2015年5月9日土曜日

[AD FS]Windows Server Technical Preview 2のAD FSファーストレビュー（管理GUI編）

先日第2弾が公開された次期Windows ServerのTechnical PreviewのAD FSがどう変わったのか確認してみたいと思います。

第一印象ですが、かなり便利・かつ高機能になっている印象です。

私なりのポイントですが、以下の5点だと思います。（まだ触り切れていないのでどこまで使えるかは微妙ですが）

PowerShellでしか出来なかった操作がかなりの範囲でGUIで操作できるようになった（OAuthのクライアント登録とかScope登録とか）
OpenID Connect Discoveryに対応した（限定的ではありますが）
Microsoft Azure MFAが最初から組み込まれた
VPNアクセス用の証明機関としての機能が付いた（？）
Web Application Proxyの管理GUIが統合された（？）

※？マークはそれっぽいメニューが存在するだけなので、どう動くのかはまだわかっていません。

また、結局Blogには投稿できませんでしたが、前回のPreviewから

OpenID Connectへの対応
OAuth2.0への対応の改善（Implicit、Client Credentialへの対応）

がなされています。
（検証結果をまとめている時間がなかっただけなので、まとめたら改めて公開したいと思います）

ということで今回は管理ツール周りを見ていきたいと思います。

◆メニュー構成
管理GUIの左ペインを見ると以下の5項目でメニューが構成されています。

Service
Access Control Policies
Relying Party Trusts
Claims Provider Trusts
Clients

Windows Server 2012R2では

サービス
信頼関係
認証ポリシー

の3項目でした。
サービスはそのまま、以前は信頼関係メニューの中にあったRelying Party Trust（証明書利用者信頼）とClaims Provider Trusts（要求プロバイダー信頼）がトップレベルに昇格、Access Control PoliciesとClientsが新規に追加され、認証ポリシーが消えた、という感じです。

では、それぞれ順番に見ていきます。

◆Serviceメニュー
以下の9項目のサブメニューで構成されています。

Attribute Store
Authentication Methods
Certificate Authority
Certificates
Claim Descriptions
Device Registration
Endpoints
Scope Descriptions
Web Application Proxy

それぞれ簡単に解説しておきます。

Attribute Store

以前は信頼関係の配下にあったものが移動されています

Authentication Methods

以前はトップメニューにあった認証ポリシーがServiceの配下に来ています

Certificate Authority

新規に追加された項目です。VPNアクセス用の証明書の発行をする機能のようです。

Certificates

変化なしです。

Claim Descriptions

変化なしです。

Device Registration

新規に追加されています。Windows Server 2012R2ではPowerShellで設定していたものがGUIで出来るようになっています。（前回のPreviewより）

Endpoints

変化なしです。

Scope Descriptions

新規に追加されています。OAuth/OpenID ConnectのScope設定が出来ます。これも以前はPowerShellで設定していたものがGUIで出来るようになっています。

Web Application Proxy

新規に追加されています。WAPを構成した場合にここで管理できるようになるのかも知れません。

◆Access Control Policiesメニュー
新規に追加されたメニューです。
これまでClaimルールで頑張って書いていたような認可ポリシーがある程度テンプレートとして用意されています。

◆Relying Party Trustsメニュー
あらかじめ以下のRelying Partyが定義されています。

VPN Server（無効化状態）
UserInfo

Windows Server 2012R2ではここにDevice Registration Serviceが登録されていましたが、初期状態では存在しません。
また、ここにはSAMLやws-federationのRelying Partyだけではなく、OAuthの保護リソースも登録されるため、OpenID ConnectのUserInfoがここに最初から登録されています。

◆Claims Provider Trustsメニュー
ここは何も変わりません。初期値ではActive Directoryだけが登録されています。

◆Clientsメニュー
新しく出来た項目です。
ここで、OAuthのクライアント管理を行うことが出来ます。
ちなみに、Windows Server 2012R2ではPublic Clientしか登録することが出来ませんでしたが、次期バージョンからはConfidentialも登録できるようになっています。（つまり、client_secretの発行が出来、Client Credentialなどのフローで使えます）

初回なので、今回はここまでにしておきますが、次回以降でもう少し細かい部分や動きを確認していきたいと思います。

【参考】
　Windows Server Technical Preview 2のISOファイルやVHDファイルは以下よりダウンロードできます。
　　https://technet.microsoft.com/ja-jp/evalcenter/dn781243.aspx
　※もしくはMicrosoft Azure上で仮想マシンとしての提供されていますので、そちらを使うことも可能です。
　　今回は手元にISOファイルから新規インストールしました。

　尚、最初に公開されたバージョンのTechnical PreviewのAD FSについては以下のポストで紹介しています。
　[AD FS]Windows Server Technical Previewで追加された機能～PowerShell編
　　http://idmlab.eidentity.jp/2015/03/ad-fswindows-server-technical.html
　[AD FS] Windows Server Technical PreviewのAD FSを試す
　　http://idmlab.eidentity.jp/2014/10/ad-fs-windows-server-technical.html

2015年5月6日水曜日

[FIM]最新HotFixでPCNSがようやくWindows Server 2012 R2に対応

ようやくPCNS（Password Change Notification Service）がWindows Server 2012 R2のドメインコントローラに対応しました。

これでPCNSがネックでドメインコントローラをWindows Server 2012 R2へアップデート出来なかった人たちも一安心です。（どれだけいるかは・・・ですが）

ちなみにPCNSは、Active Directoryドメイン上の全ドメインコントローラ上にインストールするモジュールで、各PCや管理者によるActive Directoryのパスワード変更をフックしてFIMに通知・連携するためのモジュールです。これを使うとctrl+alt+delなどで変更したパスワードをFIMと連携している他のアプリケーションへも連携することが出来ます。

今回のForefront Identity Manager（FIM）のHotFixでは実際にPCNSのモジュールが更新されているわけではなく、FIMに同梱されているActive Directory Management Agentが更新されているところを見ると、これまでもWindows Server 2012 R2からのパスワード変更通知は受け取れていたようですが、（おそらくパスワード自体の）ハンドリングが上手く出来ていなかった、というあたりを改修したように思われます。
（パッチのリリースノートを見ても、PCNSからの通知をFIM Synchronization Serviceが受け取った際のLsaLookupNames2 APIをコールする際のドメイン・フォーマットに起因する不具合の修正が含まれていますので、このあたりがWindows Server 2012 R2対応した部分だと思われます）

他にもFIM Sync/FIM CM周りでも修正は入っているようなので、現在FIM 2010R2 SP1を運用している方は早めの適用が推奨されています。

◆前提/注意事項
と、ここまで書きましたが、今回のHotFix適用にあたり、以下の注意事項があります。

Windows Server 2012 R2に対応したのはあくまで「PCNS」

⇒FIMを導入するサーバはWindows Server 2012無印までしか対応していません。MIMを待ちましょう。

カスタムの管理エージェントを導入している人は互換性に関する不具合が出ることがあります。

管理エージェントをコンパイルした時のMicrosoft.MetadirectoryServicesEx.dllのバージョンによってはno-start-maエラーが出る場合があるので、その場合は.configファイルにバージョン互換に関する記載を追記しましょう。詳細はHotFixのダウンロードページに記載されています。
ちなみに私の環境では拙作Generic REST API Management Agentは何もしなくても問題なく動きました。

- HotFixダウンロードページ
　https://support.microsoft.com/en-us/kb/3048056
- HotFix適用によるビルド・バージョン
　FIM　： 4.1.3634.0
　BHOLD　： 5.0.2959.0