・現在公開されている情報＋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って言ってるやつです）のフローを解説しています。
特にこの辺のスライドですね。
で、実際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で可能な限り取得した結果などもお見せできれば、、と思います。仕組み上、ログイン中に発生している通信も多いので、全部がトレースできる訳ではありませんが。。。
投稿
0 件のコメント:
コメントを投稿