2/28/2017 6:07 PM © 2007 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.

マイクロソフト株式会社 デベロッパー & プラットフォーム統括本部 エバンジェリスト 安納 順一 (あんのう じゅんいち) 2/28/2017 6:07 PM セッション ID：T3-304 AD FS 2.0 のアーキテクチャと Windows Azure 連携の実装 ～ AD FS 2.0 によるシングル サインオンの実現 2 ～ マイクロソフト株式会社 デベロッパー & プラットフォーム統括本部 エバンジェリスト 安納 順一 (あんのう じゅんいち) © 2007 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.

ご注意 コードをゴリゴリ書くセッションではありません 基本的な解説は「あまり」行いません AD FS とは クレーム ベースの認証とは フェデレーションとは Appendix に基本的な情報を掲載しておりますので 参考にしてください [復習] AD FS の基礎知識

Identity はハイブリッドなテクノロジ アーキテクチャが両者に影響 両者の「架け橋」となる役割が必要 インフラ担当 開発担当 Identity 設計 コード 構築 テスト 管理 仕様変更

混乱していませんか？ ココをお話しします T1-304 T3-304 Windows Live ID platform Microsoft Federation Gateway AppFabric Access Control Service STS STS STS Active Directory Active Directory Federation Service

セッションの目的とゴール Session Objectives and Takeaways 以下のテクノロジに関する解説とデモンストレーション AD FS 2.0 のアーキテクチャ AD FS 2.0 を使用した クラウド アプリケーションとの SSO AD FS 2.0 と AppFabric ACS との相互運用 AD FS 2.0 と 他社製品 との相互運用 セッションのゴール [クラウド] ＋ [Identity] 案件における アーキテクチャ決定に必要な事項を理解し、 適切な設計と構築が行える。 または、指示を与えることができるようになる。

2/28/2017 6:07 PM アジェンダ 第 1 章 AD FS 2.0 のアーキテクチャ AD FS 2.0 の内部動作について理解し、 インフラ担当者と開発者の作業範囲を把握しましょう 第 2 章 Windows Azure platform AppFabric Access Control Service のアーキテクチャ AppFabric ACS のアーキテクチャを理解し、 「できること」と「できないこと」を把握しましょう 第 3 章 AD FS 2.0 の相互運用性 AD FS 2.0 が実装している SAML 2.0 の仕様を理解し、 他ベンダーの製品やサービスとの相互運用性の 可能性について理解しましょう © 2007 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.

[復習] STS について WIF アプリケーションとの連携 クレーム パイプライン 第 1 章 AD FS 2.0 のアーキテクチャ [復習] STS について WIF アプリケーションとの連携 クレーム パイプライン

STS (Security Token Service) の役割 セキュリティトークンの発行と管理 クラウド アプリケーションとオンプレミスの架け橋 アクセス 信頼 信頼 ACS アクセス STS 信頼 信頼できるかどうかはそれぞれのアーキテクチャに依存する トークン 信頼 STS トークン AD DS AD FS

3 種類の STS(Security Token Service) 【 AD FS 2.0 】 AD FS 2.0 高機能な STS オンプレミスに配備 any IdPs 【 ACS 】 ACS any IdPs クラウド上に 用意された STS AD FS 2.0 【 MFG 】 MFG AD FS 2.0 Microsoft Online Services 用に用意された STS T1-304 MFG：Microsoft Federation Gateway ACS : Windows Azure platform AppFabric Access Control Service 信頼

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

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

信頼 ITPRO の方へ 開発者に渡すべき情報は何なのか？について理解しましょう アクセス クラウド オンプレミス AD DS WIF アクセス クラウド 信頼 オンプレミス AD DS AD FS 2.0 トークン WIF：Windows Identity Foundation

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

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

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

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

信頼 クラウド オンプレミス AD DS AD FS 2.0 Dev の方へ WIF クラウド 信頼 オンプレミス AD DS AD FS 2.0 Dev の方へ AD FS からどこまで精度の高い情報が得られるのかを理解しましょう WIF：Windows Identity Foundation

用語について 基本的に、日本語 UI に沿った用語を使用します。 が…ちょっとアレなところもあるので、以下の対応票を参考にしてください。 対応する英語 要求 Claim, クレーム 規則 Rule, ルール 要求の種類 Claim Type, クレームタイプ 要求記述 Claim Description, クレームディスクリプション 要求 プロバイダー Claims Provider, クレーム プロバイダー 証明書利用者 Relying Party, リライング パーティ 発行承認規則 Issuance Authorization Rules 受付変換規則 Acceptance Transform Rules 発行変換規則 Issuance Transform Rules

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

要求規則 (Claim Rule) 入力された情報をルール (規則) に沿って処理し出力する 処理されたクレームは既定のパイプラインを通る 他の要求 プロバイダー 入力方向の要求 スルー AD DS AD LDS LDAP LDAP 属性 変換 出力 メンバーシップ SQL Server その他 フィルター カスタム クレーム

要求規則 の処理プロセス 要求規則セット 要求規則1 Output Claim Set Input Claim Set 要求規則2 クレーム 要求規則セット 要求規則1 条件 発行 Input Claim Set 要求規則2 Output Claim Set 要求規則 n トークン

要求規則テンプレート 要求規則を作成するためのテンプレート 作成した要求規則は1つの IdP/RP にのみ関連付けられる [LDAP 属性を要求として送信] [グループ メンバーシップを要求として送信] [入力方向の要求を変換] [入力方向の要求をパススルーまたはフィルター処理] [カスタム規則を使用して要求を送信] [入力方向の要求に基づいてユーザーを許可または拒否] [すべてのユーザーを許可]

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

カスタム規則の書式 (例) <変数>:[ <クレームの属性> == <値> ] => 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);

第 1 章のまとめ 企業間の相互運用にも AD FS 2.0 AD FS 2.0 を使用すると 【利用者】 【ITPRO】 オンプレミスの Identity でクラウド上のアプリケーションに Single Sign-On できる 【ITPRO】 クラウド アプリ用の Identity を個別に管理する必要が無い 　　※今まで通り Active Directory で! 【開発者】 アプリケーションは ID/ロール管理から解放されるため、 Identity 関連のビジネス ロジック変更に影響を受けない 企業間の相互運用にも AD FS 2.0

第 2 章 AppFabric ACS のアーキテクチャ 進化が楽しみなもう1つの STS 第 2 章 AppFabric ACS のアーキテクチャ Windows Azure platform の STS として どのような役割を担うのか

Windows Azure platform AppFabric Access Control Service V1 RESTful サービスに特化したシンプルな RP/SP 用 STS プロトコル ：OAuth WRAP トークン ：SAML 1.1,SAML 2.0,SWT 道路の混雑状況を提供するサービス 問合せ 問合せ 返答 返答 ユーザー アプリ ユーザー アプリ

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

AD FS 2.0 と ACS V1 の違い AD FS 2.0 の替わりにはなれないことに注意 AD FS 2.0 ACS V1 プロトコル SAML 2.0 WS-Federation WS-Trust OAuth WRAP (for REST service) トークン SAML 1.1 SAML 1.1/2.0 (AD FS 2.0) SWT トークン発行の 要件 AD DS による認証 セキュリティ キー SAML 1.1/2.0 トークン 役割 IdP/CP, RP/SP RP/SP Passive SSO ○ × 管理方法 管理コンソール Windows PowerShell ACM.exe コマンド ACSM Browser アプリケーションに WIF は必要か? 必要 必要ない IdP の選択 ○ 選択ページのカスタマイズも可能 × クライアントアプリケーションが IdP を意識する

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

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

ACS のトークン発行条件 (認証) セキュリティ キー AD FS 2.0 SAML 1.1/2.0 トークン SWT ・・ POST /WRAPv0.8/ HTTP/1.1 Host:<NameSpace>.accesscontrol.windows.net applies_to=http%3A%2F%2Fadatum.com%2Fservices%2F& wrap_name=adatumcustomer1& wrap_password=5znwNTZDYC39dqhFOTDtnaikd1hiuRa4XaAj3Y9kJhQ%3D ・・ applies_to=http%3A%2F%2Fadatum.com%2Fservices%2F& wrap_SAML=<…SAML Bearer Token…> ・・ applies_to=http%3A%2F%2Fadatum.com%2Fservices%2F& wrap_SWT=<…Simple Web Token…>

ACS の構成情報 Namespace Key Scope Issuer Rule InClaim OutClaim IdP/CP AD FS 2.0 AD DS RP/SP Application REST Service AppFabric ACS Namespace 信頼 Key 信頼 Scope Issuer クライアント アプリケーション Rule SAML 1.1/2.0 トークン InClaim SWT OutClaim

SWT ～ Simple Web Token ACS から発行されたトークンは検証後、 HTTP Authorization ヘッダーに格納して REST Service に POST する role=Admin%2cUser&customerName=Contoso%20Corporation&Issuer=https%3a%2f%2fmyservice.accesscontrol.windows.net%2f&Audience=http%3a%2f%2flocalhost%2fmyservice&ExpiresOn=1255912922&HMACSHA256=yuVO%2fwc58%2ftYP36%2fDM1mS%2fHr0hswpsGTWwgfvAbpL64%3d Claim 1 Claim 2 Key Claim n Issure Audience ExpiresOn HMACHA256 Hash

アプリケーション側の対応 クライアント アプリケーション AD FS 2.0 に SAML 1.1/2.0 クレームの発行を依頼 ACS に SAML 1.1/2.0 クレームを送信、SWT を受け取る SWT 内の 4 つの主要クレームを検証する 署名 : HMACHA256 発行者 : Issuer 発行先 : Audience (== applies_to) 有効期限: ExpiresOn SWT を Authorization ヘッダーに格納して POST AD FS 2.0 REST サービス REST サービス HTTP Authorization ヘッダーからクレームを直接取り出す ロールを検証しクライアント アプリケーションに アクセス許可を与える

第 2 章のまとめ クラウド上に用意された STS (ACS) により、 [オンプレミス]-[クラウド] のフェデレーションを実現 現時点で AD FS 2.0 とのフェデレーションが可能 V2 でサポート予定の機能 主要 IdP とのフェデレーション信頼 AD FS 2.0（対応済） Live ID, Facebook,Yahoo!, Google 主要プロトコルの実装 WS-Trust, WS-Federation OpenID IdP の選択画面と そのカスタマイズ Passive SSO には未対応

第 3 章 AD FS 2.0 の相互運用性 AD FS 2.0 vs. SAML 2.0

相互運用性 を考えるにあたり IdP/CP RP/SP 「相互運用」する箇所を明確にする サービス STS STS API 認証サービス プロトコル/トークン形式 プロトコル トークン形式 プロトコル トークン形式 STS の仕様 STS API サービス 属性ストア API サービス

相互運用の例 IdP/CP RP/SP プロトコルとトークンが一致していても、 実装済 予定 プロトコルとトークンが一致していても、 相互運用には連携相手の「意向 (戦略)」による (場合がある) IdP/CP RP/SP WS-Fed. AD DS AD FS 2.0 Azure App WIF OAuth WRAP ACS Azure App WLID MFG WS-Trust MFG+ WLID MSO OpenLDAP Shibboleth AD FS IIS SAML 2.0 SAML 2.0 対応製品 SAML 2.0 対応製品 OAuth OpenID Provider (OP) OpenID RP OpenID MSO: Microsoft Online Services

用語の違い AD FS 2.0 SAML 2.0 Security Token Assertion Claims セキュリティトークン Assertion アサーション Claims 要求 Assertion Attributes アサーション属性 Claims Provider (CP) 要求 プロバイダー ※ 1 Identity Provider (IdP) アイデンティティ プロバイダー Relying Party (RP) 証明書利用者 ※ 2 Service Provider (SP) サービス プロバイダー ※ 1 AD FS 1.0 では Account Partner と呼んでいた ※ 2 AD FS 1.0 では Resource Partner と呼んでいた

SAML 2.0 対応製品との相互運用性 AD FS 2.0 をサポートしている OS Windows Server 2008/R2 Entrust IdentityGuard Federation Module 9.2, GetAccess 8.0 IBM Tivoli Federated Identity Manager (TFIM) 6.2 Novell Access Manager 3.1 Ping Identity PingFederate v6.1 SAP NetWeaver Identity Management 7.2 Siemens DirX Access V8.1 AD FS 2.0 がサポートする SAML 2.0 操作モード IdP Lite, SP Lite, eGov Profile 1.5 重要

SAML 2.0 プロファイルと操作モード ～ OASIS Criteria ADFS2 ADFS2 プロファイル 機能 IdP IdP Lite SP SP Lite ECP Web ブラウザー ーSSO AuthnRequest 必須 － POST アーティーファクト アーティファクトの解決 SOAP Enhanced Client/Proxy PAOS 主体名の識別子の管理 禁止 主体名の識別子のマッピング シングル ログアウト リダイレクト 選択 IdP 検出 Cookie Furnish/process Metadata

相互運用のポイント Metadata の考慮 属性のフォーマット Name ID クレームの暗号化 署名 CRL のチェック 今回は ここを見てみましょう Metadata の考慮 属性のフォーマット Name ID クレームの暗号化 署名 CRL のチェック Appendix を ご覧ください

相互運用のポイント～ Metadata AD FS 2.0 の場合 Metadata には WS-Trust/WS-Federation に関する 記述が存在する パートナー側への読み込み時にエラーとなることがある 対処法 WS-Trust/WS-Federation に関する記載を削除する <RoleDescriptor xsi:type="fed:ApplicationServiceType“ ~ </RoleDescriptor> <RoleDescriptor xsi:type="fed:SecurityTokenServiceType” ~ </RoleDescriptor>

(参考) 相互運用性 Step by Step ガイド CA Federation Manager Oracle Identity Federation Microsoft ダウンロード センターで検索 AD FS 2.0 ※ 近日、学術情報フェデレーション (Shibboleth 2) との 　相互運用性ドキュメントを公開予定

第 3 章のまとめ [ SAML 対応 !] という表記は互換性の担保ではありません AD FS 2.0 は他社製品との [ フェデレーション信頼 ] が 可能です。ただし… Metadata の修正等 細かな対応が必要な場合があります。 大人の階段を上るには「たった 1 回の実証実験」が重要

まとめ

まとめ シングル サインオン実現の「カギ」は信頼関係です まずは社内ディレクトリ サービスの整備から 3 つのテクノロジの進化がハイブリッド環境を支えます AD FS 2.0 Windows Azure AppFabric Access Control Service Microsoft Federation Gateway Interoperability は、 マイクロソフトの重点課題です 「知っていること」＝=「強み」です 「知っている人」がプロジェクトを操れます

関連セッション 終了御礼 T1-304 Day1 15:20 ～ 16:30 次期 Microsoft Online Services の ID およびアクセス管理 ～ AD FS 2.0 によるシングル サインオンの実現 1 ～ インフラ 開発 終了御礼 T1-404 Day2 15:20 ～ 16:30 Windows Azure platform AppFabric サービス バスにおける 設計パターン、ベスト プラクティスおよびテクニック インフラ 開発 BOF-09 Day3 10:55 ～ 12:05 Silverlight と WIF (Windows Identity Foundation) の アプリケーション連携 インフラ 開発 T3-302 Day3 16:50 ～ 18:00 ポリシー ベースで ID 管理を実現する! ～ Forefront Identity Manager 2010 実践的構築手法 ～ インフラ 開発

参考サイト スピーカー (安納 順一) の Blog http://blogs.technet.com/junichia/ TechDays 2010 T4-401オンプレミス & クラウドにおける Identity 連携の全体像 http://www.microsoft.com/japan/events/techdays/2010/ Active Directory TechCenter http://technet.microsoft.com/ja-jp/activedirectory/default.aspx Geneva Team Blog http://blogs.msdn.com/b/card/ @IT Windowsで構築する、クラウド・サービスと社内システムのSSO環境 http://www.atmarkit.co.jp/fwin2k/operation/adsf2sso01/adsf2sso01_01.html Internet2 Microsoft Interop (英語) https://spaces.internet2.edu/display/SHIB2/MicrosoftInterop

ご清聴ありがとうございました！ セッション ID T3-304 アンケートにご協力ください

Appendix 復習 : AD FS の基礎知識 AD FS 2.0 要求規則セットのタイプ一覧 AD FS 2.0 既定の LDAP 属性一覧 AD FS 2.0 サーバーの構成データベース SAML 2.0 操作モードとプロファイルの一覧 AD FS 2.0 と SAML 2.0 対応製品 相互運用のポイント クレーム ベースのフェデレーションが実現する Windows Azure と ID as a Service の連携

1. 復習 : AD FS の基礎知識

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

ID & アクセス管理にまつわる課題 クラウドの登場が拍車をかける? ID 管理の複雑化 アクセス管理の複雑化 管理コストの増加 絡み合ったテクノロジ クラウドの登場が拍車をかける?

自宅 ■環境 PC スタンドアロン アプリケーションはローカル ■課題 1 台の PC を家族で共有 ■解決策 ユーザー ID を PC に登録 共有 PC

組織内 ■環境 ファイル サーバーをデータ格納庫として使用 ■課題 増え続けるユーザーの管理 リソース増加と複雑化するアクセス権の管理 ■解決策 ディレクトリ サービスの導入 DS DS：Directory Service

企業全体① ■環境 複数のアプリケーション サーバー 分散したディレクトリ サービス ■課題 ID とパスワードの統一 ■解決策 メタディレクトリ システムによる同期 HR メタディレクトリ サーバー LOB ユーザー DB Metadata DS DS Mail LOB

企業全体② ■環境 重要な情報を扱うアプリケーション ■課題 より強力な認証による資格情報の識別 ■解決策 証明書による認証/承認 DS 中間認証局 ルート認証局

企業全体③－組織間 ■環境 他部門サーバーへのアクセス ■課題 他部門ユーザーの ID 管理/認証/承認 ■解決策 クレームベースのセキュリティ DS STS DS 信頼 LOB 組織 A 組織 B STS：Security Token Service

企業間 ■環境 企業間のアプリケーション共有 ■課題 社外ユーザーの ID 管理/認証/承認 企業間のセキュリティ ポリシーの整合性 ■解決策 フェデレーション ＋ クレームベース DS STS STS 信頼 企業 A 企業 B

企業-クラウド ■環境 クラウド アプリケーションの社内利用 ■課題 社内とクラウドの認証統合 利用者の ID /素性管理 ■解決策 フェデレーション ＋ クレームベース DS STS STS 信頼 企業 A クラウド

予測される ID 管理の問題点 クレームベース セキュリティ フェデレーション セキュリティ モデル 異なる認証方式の相互運用 クレームベース セキュリティ フェデレーション セキュリティ モデル

フェデレーション関連製品群 Active Directory Federation Service 2.0 旧称 Geneva Server STS（Security Token Service） Windows CardSpace 旧称 Windows CardSpace Geneva アイデンティティ プロバイダーのセレクター Windows Identity Foundation（WIF） 旧称 Geneva Framework ID モデルのフレームワーク カスタム STS の開発

AD FS とは AD FS 1.x AD FS 2.0 WS-Federation プロトコルをサポート Web ブラウザーによるパッシブ プロファイル SAML トークンをサポート (プロトコルではない) サード パーティとの相互運用性検証済 AD FS 2.0 SAML 2.0 プロトコルを追加 SAML 1.1, Liberty Alliance ID-FF 1.2, Shibboleth 1.3 をカバー 2009 年 Kantara INITIATIVE による 相互運用性テストをパス

AD FS 2.0 の目的 誰が？ どこに？ どんな「役割」で？ アクセスできるのか？ を明確にしてサービスに渡すこと Identity ビジネス ロジックの可視化 どの 機能に？ 誰が？ どこに？ どんな「役割」で？ アクセスできるのか？ を明確にしてサービスに渡すこと 結果として SSO が容易になる

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

WS-Federation による相互運用性 AD FS v1.x をサポートしている OS Windows Server 2003 R2 Windows Server 2008/R2 WS-Federation 相互運用パートナー IBM Tivoli Federated Identity Manager CA eTrust Siteminder 6 SP5 Oracle Identity Federation Ping Identity PingFederate Novell Access Manager 3.1 Shibboleth System 1.3 Sun OpenSSO Enterprise

SAML 2.0 製品との相互運用性 AD FS 2.0 をサポートしている OS Windows Server 2008/R2 Entrust IdentityGuard Federation Module 9.2, GetAccess 8.0 IBM Tivoli Federated Identity Manager (TFIM) 6.2 Novell Access Manager 3.1 Ping Identity PingFederate v6.1 SAP NetWeaver Identity Management 7.2 Siemens DirX Access V8.1 AD FS 2.0 がサポートする SAML 2.0 操作モード IdP Lite, SP Lite, eGov Profile 1.5

AD FS の役割 ① ID 管理 サービス AD FS 処理 本体 IdP - RP フェデレーション信頼 の確立 クレームの収集とトークンの発行 コードレス ロール管理 (クレーム フロー) ID 管理 サービス 信頼 認証 AD FS ロール判定 処理 本体 トークン クレーム アプリケーション ユーザー ID 部署 役職

AD FS の役割 ② 収集 変換 処理 本体 企業 B 企業 A 組織/企業間のセキュリティ トークンのゲートウェイ サービスに合った形式に変換 ロール判定 処理 本体 信頼 AD FS or any STS AD FS or any STS トークン 認証 収集 信頼 変換 アプリケーション クレーム トークン トークン 企業 A 企業 B トークン 企業/組織の壁

クレームとは ユーザーについての詳細情報 承認に使用される ユーザー ID 年齢 パスワード 住所 資格情報（認証結果） 性別 メール アドレス 言語 役職 年収 所属部門 所属企業

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

クレームベースの認証 アプリケーションが IdP を信頼することで、 直接認証を行わない (ID 管理の必要が無い) 承認に必要な情報をクレームから取り出す アプリケーションはクレームを理解しなければならない IdP ID ストア STS アプリケーション ⑤ｸﾚｰﾑ収集 ①信頼 ID library ②アクセス ⑥ｾｷｭﾘﾃｨﾄｰｸﾝ ③ポリシー取得 ④認証/トークン要求 ⑥ｾｷｭﾘﾃｨﾄｰｸﾝ IdP：Identity Provider ユーザー

クレームベース セキュリティの利点 多元要素による身分証明精度の向上 ID/Password 以外の要素を受け入れ セキュリティ ポリシーの可視化 ロール変更への柔軟な対応 サービスとロール管理の分離 要求項目のカスタマイズ (コード変更無し) スケール アップしたアプリとの親和性 企業間認証 クラウド認証

サービスと認証/ロール管理の分離 アプリケーション 認証 ロール サービス アプリケーション 認証 ロール サービス 認証 認証 クレーム セキュリティ トークン 認証 クレーム アプリケーション クレーム解釈 認証 クレーム サービス

組織間でクレームを使うには 発行元が要求元に信頼されている 要求元は複数の発行元を信頼しうる フェデレーション セキュリティ モデル 発行元 条件 1：カードはクレジットカード会社により証明 条件 2：店舗はクレジットカード会社を信頼 ∴買い物が可能 条件 1：パスポートは日本国により証明 条件 2：諸外国は日本国を信頼 ∴入国可能

(例) 入国審査 信頼 日本国政府 米国政府 信頼 空港 入国 出国 発行 健保番号 /免許証番号 /住民票 本人 顔 指紋 ビザ 滞在可能期間 入国申請書 滞在期間 滞在先 パスポート 発行国 氏名 有効期限 旅券番号 写真 出国印 パスポート ・

フェデレーション セキュリティ モデル 信頼 日本国政府 米国政府 信頼 入国 出国 アイデンティティ プロバイダー リライング パーティ オーソリティ セキュリティ トークン 本人 顔 指紋 発行 サブジェクト クレーム 信頼 クレーム 入国 出国 リソース 健保番号 /免許証番号 /住民票 空港 ビザ 滞在期間 資格情報 クレーム 入国申請書 滞在期間 滞在先 クレーム パスポート 発行国 氏名 有効期限 旅券番号 写真 出国印 クレーム クレーム クレーム クレーム 署名 パスポート ・ クレーム クレーム クレーム クレーム

フェデレーションによる Passive SSO 手順 アイデンティティ プロバイダー リライング パーティ ID ストア STS STS Application 信頼 信頼 ７ ID library 2 3 4 5 １ 6 ユーザー

Application アクセスに必要なクレーム要求を取得 RP アクセスに必要なクレーム要求を取得 IP にアクセスして認証を行い、RP アクセスに必要なトークンを取得 RP にクレームを渡し、Application アクセスに必要なトークンを要求 Application アクセスに必要なトークン取得 ID Library にトークンを渡す ID Library はトークンを解析しクレームを取得

マイクロソフト テクノロジに置き換えると 企業 B 企業 A 信頼 信頼 ７ 3 4 １ 2 5 6 Active Directory ADFS 2.0 ADFS 2.0 Application 信頼 信頼 ７ 資格情報 を確認 WIF 3 4 １ 事前に認証し 資格情報を 取得 2 5 6 ユーザー WIF：Windows Identity Framework

ADFS と他社 STS の相互運用 企業 C 企業 B 信頼 信頼 信頼 信頼 ID Store 他社 STS ADFS 2.0 Application 信頼 信頼 WIF Active Directory Application ADFS 2.0 他社 STS 信頼 信頼

Windows CardSpace IdP RP トークン発行プロセスの安全性向上 フィッシング防止 マネージド カードには個人情報は含まれない IdP RP CardSpace を使用するようにコーディングされている ③トークンが 　発行される ②カードを選択 　すると IdP に 　転送される ①アクセスすると 　カード セレクター 　が開く カードには IdP の情報が書かれている

CardSpace 個人用カードの用途 自分自身が IdP クレームは自分で用意する マッサージ店 予約サイト 新宿西口 2010年3月1日 地域 新宿西口 予約年月日 2010年3月1日 予約時間 17:00~18:00 カードを選択するとトークンが生成されて RP に送信

2. AD FS 2.0 　要求規則セットのタイプ一覧

要求規則セット (Claim Rule Set) のタイプ 受け付け要求規則 - Acceptance Transform Rule Set 要求プロバイダー ー (AD DS, SQL Server, LDAP) から 受け入れるクレーム セット 発行承認規則 - Issuance Authorization Rule Set 証明書利用者 (RP) にアクセス可能なユーザーを明確にするための ルール。許可されたユーザーは「発行変換規則」からクレームを 受け取れるため、証明書利用者へのアクセスが可能になる。 発行変換規則 - Issuance Transform Rule Set 「受け付け要求規則」から発行されたクレーム セットを入力とし、 証明書利用者 (RP) に発行するクレームを生成する 委任承認規則 - Delegation Authorization Rule Set 他のユーザーの代理として証明書利用者 (RP) にアクセスできるかどうかを判断するためのルール 偽装承認規則 - Impersonate Authorization Rule Set ユーザーが他のユーザーを偽装してアクセスできるかどうかを 判断するためのルール。Windows PowerShell で実装する。

3. AD FS 2.0 　既定のクレームタイプ一覧

既定のクレーム タイプ 英語表記 日本語表記 E-Mail Address 電子メール アドレス Given Name 指定名 Name 名前 UPN Common Name 共通名 AD FS 1.x E-Mail Address AD FS 1.x 電子メール アドレス Group グループ AD FS 1.x UPN Role 役割 Surname 姓 PPID Name Identifier 名前 ID Authentication Method 認証方法

英語表記 日本語表記 Deny Only Group SID 拒否のみグループ SID Deny only primary SID 拒否のみプライマリ SID Deny only primary group SID 拒否のみプライマリ グループ SID Group SID グループ SID Primary Group SID プライマリ グループ SID Primary SID プライマリ SID Windows account name Windows カウント名 Authentication Instant 認証タイム スタンプ

4. AD FS 2.0 　既定の LDAP 属性一覧

既定の LDAP 属性 これ以外の ldap 属性を使用する場合には「カスタム規則」を使用 LDAP 属性 LDAP 属性 Company Department Display-Name E-Mail-Address Employee-ID Employee-Number Employee-Type Given-Name Is-Member-Of-DL Organizational-Unit-Name Organization-Name Proxy-Addresses LDAP 属性 State-Or-Province-Name Street-Address Surname Telephone-Number Title Token-Groups (SID) Token-Groups - ドメイン名を含む Token-Groups - 完全修飾ドメイン名を含む Token-Groups - 名前の指定なし User-Principal-Name SAM-Account-Name

5. AD FS 2.0 　サーバーの構成データベース

AD FS 2.0 ～ サーバー ファームと構成 DB スタンドアロン ＋ WID 低 サーバー ファーム＋ WID 可用性 5 分に 1 回の更新チェック (各サーバー→プライマリ) 機能制限が発生 SAML Token Replay Detection SAML Artifact Resolution サーバー ファーム＋ SQL Server fsconfig.exe コマンドによる構成 WID からの移行は不可 SQL Server は 1 セット クラスター構成可能 プライマリ 可用性 ADFS R/W ADFS ADFS R/O R/O セカンダリ セカンダリ 高 ADFS ADFS ADFS SQL Server R/W WID：Windows Internal Database

(参考) Token Replay Attack とは http://msdn.microsoft.com/en-us/library/ee517257.aspx 取得済のセキュリティ トークンを再利用して アクセス権を得ようとするアタック キオスク端末等でブラウザーを閉じないと危険 ブラウザーの [戻る] でトークン取得ポイントに戻れてしまう WIF には Replay を検出する機能が実装されている Replay 検出は規定でオフ 有効にするには DetectReplayedTokens 値を true

(参考) SAML Artifact Resolution とは セキュリティトークン (SAML Assertion) のリファレンス SSO を実現する トークン受け渡し手順 の 1 つ ブラウザーはトークンではなく、トークンの「Artifact」を STS から受け取り RP にリダイレクトする RP は受け取った Artifact を IdP に提示して正当性を評価 評価 OK ならば、RP は IdP から直接トークンを取得する ユーザーとサーバー間の通信帯域が細い場合に有用 3 2 STS サービス 1

6. SAML 2.0 　操作モードとプロファイルの一覧

SAML 2.0 の構成要素 アサーション (セキュリティトークン) プロトコル バインディング プロファイル メタデータ 承認に必要な情報 (属性) プロトコル IdP/SP/クライアント間のメッセージ送受信の手順 バインディング リクエストの方法 (Post/Redirect/Artifact/SOAP…) セキュリティ(SSL/TLS) プロファイル プロトコル、バインディング、アサーションの組み合わせ メタデータ 信頼する IdP や RP に関する情報 エンドポイントと使用可能なバインディング 署名、キー プロトコル アサーション

SAML 2.0 操作モード (SAML 2.0 Operational Mode) IdP IdP Lite SP SP Lite IdP Extended SP Extended Enhanced Client/Proxy (ECP) SAML Attribute Authority SAML Authorization Decision Authority SAML Authentication Authority SAML Requester Post Binding (Liberty Alliance Optional) eGov (Liberty Alliance Optional） AD FS 2.0 AD FS 2.0 AD FS 2.0

SAML 2.0 プロファイル SAML 2.0 の Use-Case アサーション/プロトコル/バインディングの組み合わせ 英語での名称 日本語での名称 Web Browser SSO Web ブラウザー SSO Artifact Resolution SSO アーティファクトの解決 Enhanced Client/Proxy SSO Enhanced Client/Proxy Name Identifier Management SSO 主体名の識別子の管理 Single Logout SSO シングル ログアウト Identity Provider Discovery SSO IdP 検出 Assertion Query/Request 識別子のアサーション要求 Name Identifier Mapping 主体名の識別子のマッピング SAML Attribute SAML 属性

7. AD FS 2.0 と SAML 2.0 対応製品 相互運用のポイント Metadata 属性のフォーマット クレームの暗号化 署名 Name ID (参考) Persistent ID と Transient ID CLR のチェック

相互運用のポイント～ Metadata AD FS 2.0 の場合 Metadata には WS-Trust/WS-Federation に関する 記述が存在する パートナー側への読み込み時にエラーとなることがある 対処法 WS-Trust/WS-Federation に関する記載を削除する <RoleDescriptor xsi:type="fed:ApplicationServiceType“ ~ </RoleDescriptor> <RoleDescriptor xsi:type="fed:SecurityTokenServiceType” ~ </RoleDescriptor>

相互運用のポイント～属性のフォーマット AD FS 2.0 の場合 属性 Format の既定値は「unspecified」 urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified (例) Shibboleth 2.0 の既定値は以下 urn:oasis:names:tc:SAML:2.0:attrname-format:uri 対処法 相手側も unspecified とする or 2 段階のクレームルールで処理する 属性から値を取得 取得した値の attrname-format を uri に変更 次のページ参照

(参考) attrname-format:uri への変換 c:[ Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add( store = "Active Directory", types = ("urn:oid:1.3.6.1.4.1.5923.1.1.1.6"), query = ";userPrincipalName;{0}", param = c.Value); c:[ Type == "urn:oid:1.3.6.1.4.1.5923.1.1.1.6"] => issue( Type = c.Type, Value = c.Value, Issuer = c.Issuer, Properties[ "http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");

相互運用のポイント～クレームの暗号化 (Encryption) AD FS 2.0 の場合 AES-256 を使用 (例) Java の場合 既定値は AES-128 対処法 相手側も AES-256 を使用する or AD FS 2.0 側で暗号化を無効にする (set-ADFSRelyingPartyTrust コマンドレット)

相互運用のポイント～署名 (Signing) AD FS 2.0 の場合 規定で SHA-256 を使用する IdP の場合は アサーション、各種応答、 ログアウト要求 SP の場合 は 認証依頼 (AuthnRequest) 、 ログアウト応答、アーティファクト GET 対処法 AD FS 2.0 側で SHA-1 を使用する or 相手側も SHA-256 を使用する

相互運用のポイント ～ Name ID Name ID とは SAML 2.0 で交換される既定のクレームの 1 つ ユーザーの識別子として使用される 様々な形式 (Format) が用意されている UPN/E-Mail/X.509 Subject Name/… Persistent Identifier/Transient Identifier など AD FS 2.0 の場合 Name ID の Format を規定しない アプリケーションによって Format を要求するものがある 対処法 AD FS 2.0 管理ツールでクレーム変換を定義する

(参考) Persistent ID と Transient ID 厳密なプライバシーが要求されるシステムで使用 誰がアクセスしているのかを 内部処理に隠ぺい 2 種類の Identity 形式 Persistent (持続) ：Account Linking Transient (一時) ：Pseudo-anonymous access   IDP の場合 RP の場合 Persistent (持続) ○ × Transient (一時) 参考サイト http://blogs.msdn.com/b/card/archive/2010/02/17/ name-identifiers-in-saml-assertions.aspx

相互連携のポイント～ CRL のチェック CRL (Certificate Revocation List)：証明書失効リスト AD FS 2.0 の場合 パートナー側の証明書に CDP (CRL 配布ポイント) Extension が付加されている場合、AD FS 2.0 は規定で CRL のチェックを行う AD FS 2.0 は CA にアクセスできなければならない パートナーのプライベート CA にはアクセスできないため、チェックに失敗 ※自己発行証明書には CDP Extension が無い 対処法 AD FS 2.0 の CDP チェックを無効にする set-ADFSClaimsProviderTrust –TargetName foo –SigningCertificateRevocationCheck None –EncryptionCertificateRevocationCheck None

クレーム ベースのフェデレーションが実現する Windows Azure と ID as a Service の連携 （ご参考） クレーム ベースのフェデレーションが実現する Windows Azure と ID as a Service の連携 Azure 時代の ID 管理と高度認証 株式会社 野村総合研究所 DI ソリューション事業部

AD FS 2.0 と IDaaS の連携例 Windows Azure SaaS A （外部ID受入) SaaS B (独自ID/PW発行) WIF WIF 同期 信頼 AD FS 2.0 信頼 国内センタ Azureアプリの ID管理を代行 Azure利用企業のID管理を代行 IDaaS(3rd Party) 高度な認証 ID管理 信頼 Azure 上のアプリ開発では、いままでよりも ID 管理や認証が悩みどころに WIF ベースのアプリ開発で、オンプレミス /IDaaS の ID管理・認証を活用 同期 IdP A AD FS 2.0 IdP B 独自 オンプレミス

ACS と IDaaS の連携例 SaaS A SaaS B IDaaS(3rd Party) 高度な認証 ACS V2 IdP A ACS を活用することで、非 WIF ベースのアプリケーションでも様々な外部 IdP を利用可能 Windows Azure SaaS A SaaS B ACS v2 がでるまでは IDaaS を信頼 国内センタ 信頼 IDaaS(3rd Party) 高度な認証 ACS V2 外部クレーム情報の統合 信頼 信頼 信頼 オンプレミス mixi IdP A AD FS 2.0 Yahoo NTT Facebook Twitter 複数の外部 IdP と 高度認証との組合せ Google and more...

2/28/2017 6:07 PM © 2010 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 © 2007 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.