2010年9月11日 技術ひろば

1. Cloudde Active Directory～シングルサインオンを実現するための処方箋～ マイクロソフト株式会社 エバンジェリスト 安納 順一（あんのう じゅんいち） http://blogs.technet.com/junichia/

2. 本日のテーマ アプリケーションがクラウドにスケールアウトしたとき、 「認証」と「承認」の仕組みはどう変わるのか？ 既存の Active Directory は生かせるのか？ 夢のシングルサインオンは可能なのか？ についてお話しします。

3. ID を使用する環境 アプリケーション在るところ「ID」在り 企業全体 クラウド 企業：クラウド 企業間 自宅 企業：クラウド 企業全体 組織内 組織間 組織内

4. 予測される ID 管理の問題点 見えない利用者の ID 管理/認証/承認 異なる認証方式の相互運用 ディレクトリサービスの設置が困難 クレームベース セキュリティ フェデレーション セキュリティ モデル

8. 氏名

9. 有効期限

10. 旅券番号

11. 写真

12. 出国印パスポート ・ ・

16. 氏名

17. 有効期限

18. 旅券番号

19. 写真

20. 出国印クレーム クレーム クレーム パスポート ・ ・ クレーム 署名 クレーム クレーム クレーム クレーム

21. クレーム（主張）とは アプリケーションに渡すユーザー自身の属性 承認に使用される ユーザー ID 年齢 パスワード 住所 資格情報（認証結果） 性別 メール アドレス 言語 役職 年収 所属部門 所属企業

22. セキュリティ トークン パッケージ化されたクレーム 発行者の署名によって信頼性を担保 STS ( Security Token Service ) が生成する セキュリティトークン クレーム 1 クレーム 2 クレーム n クレームの 発行元による 署名

24. Identity 管理ポリシーの違い

25. アプリケーション側の対応

26. Single Sign-On/Off への適用Active Directory アプリ1 LA空港 日本国 プロトコル 情報の整形 情報の解釈 情報 プロトコル 情報 情報 アプリ2 OpenLDAP 中国 ﾋｰｽﾛｰ プロトコル 情報の整形 プロトコル 情報の解釈 情報 情報 情報

28. STS によりアプリケーション側の処理を削減

29. 情報はセキュリティトークンに格納して受け渡し米政府 STS STS Active Directory アプリ1 日本国 LA空港 プロトコル 情報の整形 情報の解釈 プロトコル 情報 プロトコル フェデレーション信頼 情報 情報 ｲｷﾞﾘｽ政府 STS アプリ2 OpenLDAP STS 中国 ﾋｰｽﾛｰ プロトコル プロトコル プロトコル 情報の整形 情報の解釈 情報 情報 情報

31. アプリケーションは受け取ったロールを解釈するだけActive Directory Federation Service Active Directory Federation Service2.0 STS STS Active Directory アプリ1 プロトコル 情報の整形 情報の解釈 プロトコル 情報 プロトコル 信頼 情報 情報 Windows Identity Foundation

32. 認証/ロール管理からの分離 アプリケーション これまでの方式 認証 ロール サービス アプリケーション 認証 ロール サービス 認証 セキュリティ トークン アプリケーション クレームに対応 認証 クレーム クレーム解釈 サービス クレーム 認証

36. STS 間でフェデレーション信頼を構築企業A 企業B RP/SP IdP/CP 信頼 ④アクセス AD DS ①認証 WIF ③Token発行 AD FS 2.0 AD FS 2.0 Application ②Token発行 クレームストア IdP：Identity Provider CP：Claims Provider RP : Relying Party SP : Service Provider

39. WIF アプリケーションとSSOの仕組み クラウド上に Identity 情報を用意せずに、クレームによるアクセス承認が可能 7 WIF 信頼 クラウド オンプレミス AD DS AD FS2.0 3 8 5 4 6 2 1 WIF：Windows Identity Foundation

40. WS-Federation (Passive SSO) の流れ オンプレミスの AD DS にログオン依頼 AD DS からクレデンシャルが送信されクライアントに保存 ------------ Windows Azure 上のアプリケーションにアクセス クレーム ポリシーをアプリケーションから受け取り、STS(AD FS 2.0) にリダイレクト 属性ストアである AD DS からクレームを収集 集めたクレームに署名をしてセキュリティトークンを生成し、Windows Azure アプリケーションに送信 アプリケーションはセキュリティトークンを受け取り、Windows Identity Foundation(WIF) を使用してクレームを取り出し、評価する 画面がブラウザーに送られる

41. WIF アプリケーションの構造 WIF (Windows Identity Foundation) を使用してセキュリティー トークンからクレームを取り出す WIF は WS-Federation/WS-Trustをサポート ロールは既にトークンにセットされているので評価するだけでOK AD FS 2.0 ASP.NET クレームの評価 トークン ロール判定 Windows Identity Foundation 各種処理 .NET Framework 4 ブラウザー

42. 「信頼」とは？ 物理的には メタデータ/証明書/暗号化キーを事前に交換 お互いの「すり替わり」を防止 データの横取りを防止 RP/SP IdP/CP 信頼 Metadata Metadata URI URI 精神的には IdP 側 の Identity/Role 管理責任を信頼 RP 側の クレーム管理責任を信頼

43. クレームの構造と識別方法 Microsoft.IdentityModel.Claims http://msdn.microsoft.com/ja-jp/library/microsoft.identitymodel.claims.aspx これらの値で クレームを識別する Claims ClaimType Claim Value Claim Claim Issuer Claim OriginalIssuer ValueType subject

44. アプリケーション作成時の留意点 空の属性はクレームに含まれない ゆえにトークンにも含まれない 安易に「既定値」を使用するととんでもないことに! 氏名 = 安納 順一 IdP 会社名 = マイクロソフト株式会社 役職＝ (空) RP 氏名 = 安納 順一 会社名 = マイクロソフト株式会社

45. サポートされているプロトコルとトークン形式 AD FS 2.0 WIF パッシブ SAML WebSSO SAML 2.0 トークン パッシブ WS-Federation SAML1.1 トークン アクティブ WS-Trust (CardSpace 対応含む) SAML 2.0トークン SAML 1.1 トークン

46. AD FS 2.0 ～クレーム パイプライン 証明書利用者 (RP) クレームストア トークン ② 承認する ③ 発行する ① 受付ける 発行 変換 規則 output 受け 付け 変換 規則 input 発行 承認 規則 input output output input OK/ NG switch 要求プロバイダー信頼 (Claims Provider Trusts) 証明書利用者信頼 (Relying Party) 要求規則 (Claim Rule)

47. 要求規則 の処理プロセス クレーム 要求規則セット 要求規則1 発行 条件 Input Claim Set 要求規則2 OutputClaim Set 要求規則 n テンプレートが用意されている トークン

48. カスタム規則 テンプレートに用意されていないルールは自作することができる 「要求規則言語」を使用する 条件部 発行部 条件文 1 True => 発行文 条件文 2 && False && 入力方向のクレーム/属性をチェックし、すべての条件が True の場合に「発行部」が実行される。条件部が無い場合には無条件で True とみなされる。 条件部 オプション 発行部 発行するトークンタイプと、そこに格納する属性/値を指定する。 必須

49. カスタム規則の書式 (例) <変数>:[ <クレームの属性> == <値> ] => issue ( <発行書式>); パス スルー (入力クレームをそのまま出力クレームに転送) c:[type == “http://schemas.xx.org/claims/Email”] => issue (claim = c) ; ユーザー名で AD DS を検索して会社名を取り出す c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"), query = ";company;{0}", param= c.Value);

50. ここで1つの疑問が… クラウド上のアプリケーションが 社外のものだったら？？？？

52. アプリケーションが RESTfulならば こんな方法もあります

54. Windows Azure platformAppFabricAccess ControlServiceV1 RESTfulサービスに特化したシンプルな RP/SP 用STS プロトコル：OAuth WRAP トークン：SAML 1.1,SAML 2.0,SWT platform Relying Party AppFabric Access Control Service 信頼 STS REST 信頼 ③ トークン ②トークン Service Bus ① 認証 ④ 結果

55. AppFabric ACSV1 の想定シナリオ RESTful なサービスへのアクセス制御を行う 企業B 道路の混雑状況を提供するサービス REST API Request Response Request Response 企業Ａ 企業C Application Application

56. ACS を 企業内 AD との SSO に使用する ACS では Passive SSO がサポートされていないことに注意 9 信頼 ACS WRAP REST Service 5 WS-Trust 信頼 クラウド 信頼 8 オンプレミス 6 4 10 AD DS AD FS2.0 1 7 2 3 クライアント アプリケーション

57. 処理の流れ クライアント アプリケーションが AD FS 2.0 にトークン発行を依頼 AD DS からクレームを収集 AD FS 2.0 から SAML 1.1 トークン発行 トークンを ACS に送信 ACS は受け取った SAML 1.1 トークンをルールに沿って検証 SWT を生成し、クライアントに発行 クライアント アプリケーションは受け取った SWT を分解し、正しい ACS から発行されたものか等を検証 問題なければ HTTPAuthorization ヘッダーに SWT を埋め込み、REST サービスにPOST REST サービスは受け取った SWT を分解してロールを検証 ロールが正しければサービスを実行

58. まとめ

59. 3 種類の STS(Security Token Service) STS により「使用目的」と「出来ること」が異なる 【MFG】 【ACSV1】 【AD FS 2.0】 Microsoft Online Services 用に用意された STS クラウド上に 用意された STS 高機能な STS オンプレミスに配備 MFG ACS AD FS 2.0 AD FS 2.0 AD FS 2.0 AD FS2.0 any IdPs any IdPs MFG：Microsoft Federation Gateway ACS : Windows Azure platform AppFabricAccess Control Service 信頼

60. STS (Security Token Service) の役割 セキュリティトークンの発行と管理 クラウド アプリケーションとオンプレミスの架け橋 アクセス 信頼 信頼 ACS アクセス STS 信頼 トークン 信頼 STS トークン AD DS AD FS

61. AD FS 2.0 と ACS V1 の違い ACS V1は AD FS 2.0 の替わりにはなれないことに注意 IdPとの連携が必要

62. シナリオによって使用するSTSが異なる IdP/CP RP/SP REST クラウド ACS V1 WIF AD FS 2.0 REST オンプレミス WIF AD FS 2.0 AD DS

63. ACS V2 はAD FS 2.0 以外の IdP にも対応予定 ACS V2 が万能になるわけではありません！ IdP/CP RP/SP REST クラウド ACS V2 WIF AD FS 2.0 REST オンプレミス WIF AD FS 2.0 AD DS

64. © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.