Transcript AD FS 2.0 - Microsoft

セッション ID：T3-304
AD FS 2.0 のアーキテクチャと
Windows Azure 連携の実装
～ AD FS 2.0 によるシングル サインオンの実現 2 ～
マイクロソフト株式会社
デベロッパー & プラットフォーム統括本部
エバンジェリスト
安納 順一 (あんのう じゅんいち)
ご注意
コードをゴリゴリ書くセッションではありません
基本的な解説は「あまり」行いません
AD FS とは
クレーム ベースの認証とは
フェデレーションとは
Appendix に基本的な情報を掲載しておりますので
参考にしてください
[復習] AD FS の基礎知識
3
Identity はハイブリッドなテクノロジ
アーキテクチャが両者に影響
両者の「架け橋」となる役割が必要
インフラ担当
開発担当
設計
構築
管理
4
コード
Identity
テスト
仕様変更
混乱していませんか？
T1-304
Windows
Live ID
Microsoft
Federation
Gateway
STS
ココをお話しします
T3-304
platform
AppFabric
Access Control
STS Service
STS
Active
Directory
5
Active Directory
Federation Service
セッションの目的とゴール
Session Objectives and Takeaways
セッションの目的
以下のテクノロジに関する解説とデモンストレーション
AD
AD
AD
AD
FS
FS
FS
FS
2.0
2.0
2.0
2.0
のアーキテクチャ
を使用した クラウド アプリケーションとの SSO
と AppFabric ACS との相互運用
と 他社製品 との相互運用
セッションのゴール
[クラウド] ＋ [Identity] 案件における
アーキテクチャ決定に必要な事項を理解し、
適切な設計と構築が行える。
または、指示を与えることができるようになる。
6
アジェンダ
第 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 の仕様を理解し、
他ベンダーの製品やサービスとの相互運用性の
可能性について理解しましょう
7
第1章
AD FS 2.0 のアーキテクチャ
[復習] STS について
WIF アプリケーションとの連携
クレーム パイプライン
STS (Security Token Service) の役割
セキュリティトークンの発行と管理
クラウド アプリケーションとオンプレミスの架け橋
信頼
信頼
ACS
STS
信頼できるかどう
かはそれぞれの
アーキテクチャに
依存する
AD DS
9
信頼
信頼
STS
AD FS
3 種類の STS(Security Token Service)
STS により「使用目的」と「出来ること」が異なる
【 AD FS 2.0 】
高機能な STS
オンプレミスに配備
any
IdPs
AD FS 2.0
AD FS
2.0
【 ACS 】
クラウド上に
用意された STS
【 MFG 】T1-304
Microsoft Online Services
用に用意された STS
MFG
ACS
AD FS
2.0
any
IdPs
AD FS
2.0
MFG：Microsoft Federation Gateway
ACS : Windows Azure platform AppFabric Access Control Service
10
信頼
WIF アプリケーションとの連携
クラウド上に Identity 情報を用意せずに、
クレームによるアクセス承認が可能
WIF
7
3
8
クラウド
オンプレミス
AD DS
AD FS 2.0
5
4
1
11
2
WIF：Windows Identity Foundation
6
WS-Federation (Passive SSO) の流れ
1. オンプレミスの AD DS にログオン依頼
2. AD DS からクレデンシャルが送信されクライアントに保存
-----------3. Windows Azure 上のアプリケーションにアクセス
4. クレーム ポリシーをアプリケーションから受け取り、
STS (AD FS 2.0) にリダイレクト
5. 属性ストアである AD DS からクレームを収集
6. 集めたクレームに署名をしてセキュリティトークンを生成
し、Windows Azure アプリケーションに送信
7. アプリケーションはセキュリティトークンを受け取り、
Windows Identity Foundation (WIF) を使用してクレーム
を取り出し、評価する
8. 画面がブラウザーに送られる
12
ITPRO の方へ
開発者に渡すべき情報
は何なのか？について
理解しましょう
WIF
クラウド
オンプレミス
AD DS
13
AD FS 2.0
WIF：Windows Identity Foundation
「信頼」とは？
物理的には
メタデータ/証明書/暗号化キーを事前に交換
お互いの「すり替わり」を防止
データの横取りを防止
IdP/CP
Metadata
URI
信頼
RP/SP
Metadata
精神的には
IdP 側 の Identity/Role 管理責任を信頼
RP 側の クレーム管理責任を信頼
14
URI
WIF アプリケーションの構造
WIF (Windows Identity Foundation) を使用して
セキュリティー トークンからクレームを取り出す
WIF は WS-Federation/WS-Trust をサポート
ロールは既にトークンに
セットされているので
評価するだけでOK
AD FS 2.0
ASP.NET
Windows Identity
Foundation
.NET Framework 4
ブラウザー
15
クレームの評価
ロール判定
各種処理
クレームの構造と識別方法
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
16
アプリケーション作成時の留意点
空の属性はクレームに含まれない
ゆえにトークンにも含まれない
安易に「既定値」を使用するととんでもないことに!
IdP
氏名 = 安納 順一
会社名 = マイクロソフト株式会社
役職＝ (空)
RP
氏名 = 安納 順一
会社名 = マイクロソフト株式会社
17
WIF
クラウド
オンプレミス
AD DS
18
AD FS 2.0
WIF：Windows Identity Foundation
Dev の方へ
AD FS からどこまで精度
の高い情報が得られるの
かを理解しましょう
用語について
基本的に、日本語 UI に沿った用語を使用します。
が…ちょっとアレなところもあるので、以下の対応票を参考にしてくださ
い。
19
日本語
対応する英語
要求
Claim, クレーム
規則
Rule, ルール
要求の種類
Claim Type, クレームタイプ
要求記述
Claim Description, クレームディスクリプション
要求 プロバイダー
Claims Provider, クレーム プロバイダー
証明書利用者
Relying Party, リライング パーティ
発行承認規則
Issuance Authorization Rules
受付変換規則
Acceptance Transform Rules
発行変換規則
Issuance Transform Rules
AD FS 2.0 ～クレーム パイプライン
証明書利用者
(RP)
要求プロバイダー/属性ストア
要求プロバイダー信頼
(Claims Provider Trusts)
20
要求規則 (Claim Rule)
OK/
NG
output
発行
変換
規則
input
発行
承認
規則
output
受け
付け
変換
規則
input
③ 発行する
output
② 承認する
input
① 受付ける
トークン
switch
証明書利用者信頼 (Relying Party)
要求規則 (Claim Rule)
入力された情報をルール (規則) に沿って処理し出力する
処理されたクレームは既定のパイプラインを通る
要求規則
他の要求
プロバイダー
AD DS
AD LDS
LDAP
SQL Server
その他
21
入力方向の要求
LDAP 属性
メンバーシップ
カスタム クレーム
スルー
変換
フィルター
出力
要求規則 の処理プロセス
クレーム
要求規則セット
Input Claim Set
条件
Output Claim Set
要求規則1
発行
要求規則2
要求規則 n
トークン
22
要求規則テンプレート
要求規則を作成するためのテンプレート
作成した要求規則は1つの IdP/RP にのみ関連付けられる
[LDAP 属性を要求として送信]
[グループ メンバーシップを要求として送信]
[入力方向の要求を変換]
[入力方向の要求をパススルーまたはフィルター処理]
[カスタム規則を使用して要求を送信]
[入力方向の要求に基づいてユーザーを許可または拒否]
[すべてのユーザーを許可]
23
カスタム規則の定義
テンプレートに用意されていないルールは
自作することができる
「要求規則言語」を使用する
発行部
条件部
条件文 1
&&
&&
条件文 2
True
=>
発行文
False
条件部 入力方向のクレーム/属性をチェックし、
オプション すべての条件が True の場合に「発行部」が実行され
る。条件部が無い場合には無条件で True とみなされ
る。
発行部 発行するトークンタイプと、
そこに格納する属性/値を指定する。
必須
24
カスタム規則の書式 (例)
<変数>:[ <クレームの属性> == <値> ]
=> issue ( <発行書式> );
パス スルー (入力クレームをそのまま出力クレームに転送)
c:[type == “http://schemas.xx.org/claims/Email”]
=> issue (claim = c) ;
ユーザー名で AD DS を検索して会社名を取り出す
c:[Type ==
"http://schemas.microsoft.com/ws/2008/06/identit
y/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);
25
第 1 章のまとめ
AD FS 2.0 を使用すると
【利用者】
オンプレミスの Identity でクラウド上のアプリケーションに Single
Sign-On できる
【ITPRO】
クラウド アプリ用の Identity を個別に管理する必要が無い
※今まで通り Active Directory で!
【開発者】
アプリケーションは ID/ロール管理から解放されるため、
Identity 関連のビジネス ロジック変更に影響を受けない
企業間の相互運用にも AD FS 2.0
26
進化が楽しみなもう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
道路の混雑状況を提供するサービス
問 返
合 答
せ
ユーザー
アプリ
28
問 返
合 答
せ
ユーザー
アプリ
Windows Azure platform
AppFabric Access Control Service V1
RESTful サービスに特化したシンプルな RP/SP 用 STS
：OAuth WRAP
：SAML 1.1,SAML 2.0,SWT
AppFabric
Access Control Service
信頼
Service Bus
セキュリティ キー
or
SAML 1.1/2.0
トークン
or
SWT
29
STS
platform
信頼
REST
Relying Party
プロトコル
トークン
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 2.0
• SAML 1.1/2.0 (AD FS 2.0)
• SWT
トークン発行の
要件
• AD DS による認証
• セキュリティ キー
• SAML 1.1/2.0 トークン
• SWT
役割
IdP/CP, RP/SP
RP/SP
Passive SSO
○
×
管理方法
• 管理コンソール
• ACM.exe コマンド
• ACSM Browser
•
30
Windows PowerShell
アプリケーション
に WIF は必要か?
必要
必要ない
IdP の選択
○ 選択ページのカスタ × クライアントアプリケーショ
マイズも可能
ンが IdP を意識する
ACS を 企業内 AD との SSO に使用する
ACS では Passive SSO がサポートされていないことに注意
WS-Trust
信頼
ACS
WRAP
9
REST
Service
5
クラウド
信
頼
オンプレミス
AD DS
4 6
8
10
AD FS 2.0
2
1
7
3
クライアント
アプリケーション
31
処理の流れ
1. クライアント アプリケーションが AD FS 2.0 に
トークン発行を依頼
2. AD DS からクレームを収集
3. AD FS 2.0 から SAML 1.1 トークン発行
4. トークンを ACS に送信
5. ACS は受け取った SAML 1.1 トークンをルールに沿って検証
6. SWT を生成し、クライアントに発行
7. クライアント アプリケーションは受け取った SWT を分解
し、正しい ACS から発行されたものか等を検証
8. 問題なければ HTTP Authorization ヘッダーに SWT を埋め
込み、REST サービスに POST
9. REST サービスは受け取った SWT を分解してロールを検証
10. ロールが正しければサービスを実行
32
ACS のトークン発行条件 (認証)
セキュリティ キー
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
AD FS 2.0 SAML 1.1/2.0 トークン
・・
applies_to=http%3A%2F%2Fadatum.com%2Fservices%2F&
wrap_SAML=<…SAML Bearer Token…>
SWT
・・
applies_to=http%3A%2F%2Fadatum.com%2Fservices%2F&
wrap_SWT=<…Simple Web Token…>
33
ACS の構成情報
IdP/CP
RP/SP
AD FS
AD DS 2.0
AppFabric ACS
信頼
Namespace
Key
Scope
クライアント
アプリケーション
34
Issuer
SAML 1.1/2.0
トークン
Rule
InClaim
SWT
OutClaim
Application
REST Service
信頼
SWT ～ Simple Web Token
ACS から発行されたトークンは検証後、
HTTP Authorization ヘッダーに格納して REST Service
に POST する
role=Admin%2cUser&custo
merName=Contoso%20Corp
oration&Issuer=https%3a%
2f%2fmyservice.accesscontr
ol.windows.net%2f&Audienc
e=http%3a%2f%2flocalhost
%2fmyservice&ExpiresOn=1
255912922&HMACSHA256=
yuVO%2fwc58%2ftYP36%2f
DM1mS%2fHr0hswpsGTWw
gfvAbpL64%3d
35
Key
Hash
Claim 1
Claim 2
Claim n
Issure
Audience
ExpiresOn
HMACHA256
アプリケーション側の対応
クライアント アプリケーション
AD FS 2.0 に SAML 1.1/2.0 クレームの発行を依頼
ACS に SAML 1.1/2.0 クレームを送信、SWT を受け取る
SWT 内の 4 つの主要クレームを検証する
署名
:
発行者 :
発行先 :
有効期限:
HMACHA256
AD FS 2.0
Issuer
REST サービス
Audience (== applies_to)
ExpiresOn
SWT を Authorization ヘッダーに格納して POST
REST サービス
HTTP Authorization ヘッダーからクレームを直接取り出す
ロールを検証しクライアント アプリケーションに
アクセス許可を与える
36
第 2 章のまとめ
クラウド上に用意された STS (ACS) により、
[オンプレミス]-[クラウド] のフェデレーションを実現
Passive SSO には未対応
ACS は発展中です
現時点で AD FS 2.0 とのフェデレーションが可能
V2 でサポート予定の機能
主要 IdP とのフェデレーション信頼
AD FS 2.0（対応済）
Live ID, Facebook,Yahoo!,
Google
主要プロトコルの実装
WS-Trust, WS-Federation
OpenID
IdP の選択画面と
そのカスタマイズ
37
第3章
AD FS 2.0 の相互運用性
AD FS 2.0 vs. SAML 2.0
相互運用性 を考えるにあたり
「相互運用」する箇所を明確にする
IdP/CP
RP/SP
STS の仕様
サービス
API
認証サービス
STS
プロトコル
プロトコル/トークン形式
トークン形式
属性ストア
STS
API
サービス
API
サービス
39
相互運用の例
実装済
予定
プロトコルとトークンが一致していても、
相互運用には連携相手の「意向 (戦略)」による (場合がある)
IdP/CP
AD DS
WLID
OpenLDAP
RP/SP
AD FS 2.0
WS-Fed.
MFG
OAuth
WRAP
ACS
Azure App
Shibboleth
WSTrust
MFG+
WLID
MSO
SAML
2.0
AD FS
IIS
SAML 2.0 対応製品
OpenID Provider (OP)
OAuth
OpenID
40
MSO: Microsoft Online Services
WIF Azure App
SAML 2.0 対応製品
OpenID RP
用語の違い
AD FS 2.0
Security Token
SAML 2.0
Assertion
セキュリティトークン
アサーション
Claims
Assertion Attributes
要求
アサーション属性
Claims Provider (CP)
Identity Provider (IdP)
要求 プロバイダー ※ 1
アイデンティティ プロバイダー
Relying Party (RP)
Service Provider (SP)
証明書利用者 ※ 2
サービス プロバイダー
※ 1 AD FS 1.0 では Account Partner と呼んでいた
※ 2 AD FS 1.0 では Resource Partner と呼んでいた
41
SAML 2.0 対応製品との相互運用性
AD FS 2.0 をサポートしている OS
Windows Server 2008/R2
検証済み SAML 2.0 相互運用性パートナー
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
42
SAML 2.0 プロファイルと操作モード
～ OASIS Criteria
ADFS2
ADFS2
IdP Lite SP
SP Lite ECP
プロファイル
機能
IdP
Web ブラウザー ーSSO
AuthnRequest
必須 必須
必須 必須
－
POST
必須 必須
必須 必須
－
必須
必須 必須
－
アーティーファクト 必須
アーティファクトの解決
SOAP
必須 必須
必須 必須
－
Enhanced Client/Proxy
PAOS
必須 必須
必須 必須
必須
主体名の識別子の管理
必須 禁止
必須 禁止
－
主体名の識別子のマッピング
必須 禁止
必須 禁止
－
リダイレクト
必須 必須
必須 必須
－
SOAP
必須 選択
必須 選択
－
Cookie
必須 必須
選択 選択
－
Furnish/process
Metadata
選択 選択
選択 選択
－
シングル ログアウト
IdP 検出
43
相互運用のポイント
Metadata の考慮
属性のフォーマット
Name ID
クレームの暗号化
署名
CRL のチェック
44
今回は
ここを見てみましょう
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>
45
(参考) 相互運用性 Step by Step ガイド
以下の製品との相互運用性ドキュメントが
Step By Step として公開済
CA Federation Manager
Oracle Identity Federation
Microsoft ダウンロード センターで検索
AD FS 2.0
※ 近日、学術情報フェデレーション (Shibboleth 2) との
相互運用性ドキュメントを公開予定
46
第 3 章のまとめ
[ SAML 対応 !] という表記は互換性の担保ではありません
AD FS 2.0 は他社製品との [ フェデレーション信頼 ] が
可能です。ただし…
Metadata の修正等 細かな対応が必要な場合があります。
大人の階段を上るには「たった 1 回の実証実験」が重要
47
まとめ
まとめ
シングル サインオン実現の「カギ」は信頼関係です
まずは社内ディレクトリ サービスの整備から
3 つのテクノロジの進化がハイブリッド環境を支えます
AD FS 2.0
Windows Azure AppFabric Access Control Service
Microsoft Federation Gateway
Interoperability は、
マイクロソフトの重点課題です
「知っていること」＝=「強み」です
「知っている人」がプロジェクトを操れます
49
関連セッション
50
終了御礼
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
51
ご清聴ありがとうございました！
セッション ID
T3-304
アンケートにご協力ください
Appendix
1.
2.
3.
4.
5.
6.
7.
8.
復習 : AD FS の基礎知識
AD FS 2.0 要求規則セットのタイプ一覧
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 を使用する環境
クラウド
55
企
業
間
ID & アクセス管理にまつわる課題
ID 管理の複雑化
アクセス管理の複雑化
管理コストの増加
絡み合ったテクノロジ
クラウドの登場が拍車をかける?
56
自宅
• ユーザー ID を PC に登録
57
組織内
• ディレクトリ サービスの導入
58
企業全体①
• メタディレクトリ システムによる同期
Metadata
59
企業全体②
• 証明書による認証/承認
60
企業全体③－組織間
• クレームベースのセキュリティ
信頼
61
企業間
• フェデレーション ＋ クレームベース
信頼
62
企業-クラウド
• フェデレーション ＋ クレームベース
信頼
63
予測される ID 管理の問題点
見えない利用者の ID 管理/認証/承認
異なる認証方式の相互運用
クレームベース セキュリティ
フェデレーション セキュリティ モデル
64
フェデレーション関連製品群
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 の開発
65
AD FS とは
AD FS 1.x
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 による
相互運用性テストをパス
66
AD FS 2.0 の目的
Identity ビジネス ロジックの可視化
誰が？
どの
機能に？
どこに？
どんな「役割」で？
アクセスできるのか？
を明確にしてサービスに渡すこと
結果として SSO が容易になる
67
AD FS 2.0 でサポートされている
プロトコルとトークン
パッシブ SAML WebSSO
SAML 2.0 トークン
パッシブ WS-Federation
SAML 1.1 トークン
アクティブ WS-Trust
(CardSpace 対応含む)
SAML 2.0 トークン
SAML 1.1 トークン
68
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
69
SAML 2.0 製品との相互運用性
AD FS 2.0 をサポートしている OS
Windows Server 2008/R2
検証済み SAML 2.0 相互運用性パートナー
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
70
AD FS の役割 ①
IdP - RP フェデレーション信頼 の確立
クレームの収集とトークンの発行
コードレス
ID 管理
認証
ロール管理
(クレーム フロー)
信頼
AD FS
トークン
ユーザー ID
部署
役職
71
サービス
ロ
ー
ル
判
定
処理
本体
アプリケーション
AD FS の役割 ②
組織/企業間のセキュリティ トークンのゲートウェイ
サービスに合った形式に変換
AD FS
AD FS
or any STS
or any STS
信頼
収集
変換
企業 B
企業/組織の壁
72
処理
本体
アプリケーション
トークン
企業 A
ロ
ー
ル
判
定
クレームとは
ユーザーについての詳細情報
承認に使用される
73
セキュリティ トークン
パッケージ化されたクレーム
発行者の署名によって信頼性を担保
STS ( Security Token Service ) が生成する
74
クレームベースの認証
①信頼
75
クレームベース セキュリティの利点
多元要素による身分証明精度の向上
ID/Password 以外の要素を受け入れ
セキュリティ ポリシーの可視化
ロール変更への柔軟な対応
サービスとロール管理の分離
要求項目のカスタマイズ (コード変更無し)
スケール アップしたアプリとの親和性
企業間認証
クラウド認証
76
サービスと認証/ロール管理の分離
アプリケーション
アプリケーション
アプリケーション
77
組織間でクレームを使うには
発行元が要求元に信頼されている
要求元は複数の発行元を信頼しうる
78
(例) 入国審査
信頼
信頼
79
フェデレーション セキュリティ モデル
信頼
信頼
80
フェデレーションによる Passive SSO 手順
信頼
ユーザー
81
信頼
① Application アクセスに必要なクレーム要求を取得
② RP アクセスに必要なクレーム要求を取得
③ IP にアクセスして認証を行い、RP アクセスに必要
なトークンを取得
④ RP にクレームを渡し、Application アクセスに必要
なトークンを要求
⑤ Application アクセスに必要なトークン取得
⑥ ID Library にトークンを渡す
⑦ ID Library はトークンを解析しクレームを取得
82
マイクロソフト テクノロジに置き換えると
Active
Directory
ADFS 2.0
ADFS 2.0
信頼
信頼
WIF
83
ADFS と他社 STS の相互運用
企業 C
ID Store
ADFS 2.0
他社 STS
信頼
信頼
WIF
ADFS 2.0
他社 STS
信頼
84
信頼
Active
Directory
Windows CardSpace
トークン発行プロセスの安全性向上
フィッシング防止
マネージド カード (IdP が発行したカード) と個人用 カード
マネージド カードには個人情報は含まれない
85
CardSpace 個人用カードの用途
自分自身が IdP
クレームは自分で用意する
新宿西口
予約年月日 2010年3月1日
17:00~18:00
予約時間
地域
86
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 で実装する。
88
3. AD FS 2.0
既定のクレームタイプ一覧
既定のクレーム タイプ
英語表記
日本語表記
E-Mail Address
電子メール アドレス
Given Name
指定名
Name
名前
UPN
UPN
Common Name
共通名
AD FS 1.x E-Mail Address
AD FS 1.x 電子メール アドレス
Group
グループ
AD FS 1.x UPN
AD FS 1.x UPN
Role
役割
Surname
姓
PPID
PPID
Name Identifier
名前 ID
Authentication Method
認証方法
90
英語表記
日本語表記
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
認証タイム スタンプ
91
4. AD FS 2.0
既定の LDAP 属性一覧
既定の LDAP 属性
これ以外の ldap 属性を使用する場合には「カスタム規則」を使用
LDAP 属性
LDAP 属性
Company
State-Or-Province-Name
Department
Street-Address
Display-Name
Surname
E-Mail-Address
Telephone-Number
Employee-ID
Title
Employee-Number
Token-Groups (SID)
Employee-Type
Token-Groups - ドメイン名を含む
Given-Name
Is-Member-Of-DL
Token-Groups - 完全修飾ドメイン名
を含む
Organizational-Unit-Name
Token-Groups - 名前の指定なし
Organization-Name
User-Principal-Name
Proxy-Addresses
SAM-Account-Name
93
5. AD FS 2.0
サーバーの構成データベース
AD FS 2.0 ～ サーバー ファームと構成 DB
低
可
用
性
高
スタンドアロン ＋ WID
サーバー ファーム＋ WID
各サーバーが WID を持つ
5 分に 1 回の更新チェック
(各サーバー→プライマリ)
機能制限が発生
SAML Token Replay Detection
SAML Artifact Resolution
サーバー ファーム＋ SQL Server
fsconfig.exe コマンドによる構成
WID からの移行は不可
SQL Server は 1 セット
クラスター構成可能
WID：Windows Internal Database
95
プライマリ
ADFS
R/W
ADFS
R/O
セカンダリ
ADFS
R/O
セカンダリ
ADFS ADFS ADFS
SQL
Server
R/W
(参考) Token Replay Attack とは
http://msdn.microsoft.com/en-us/library/ee517257.aspx
取得済のセキュリティ トークンを再利用して
アクセス権を得ようとするアタック
キオスク端末等でブラウザーを閉じないと危険
ブラウザーの [戻る] でトークン取得ポイントに戻れてしまう
WIF には Replay を検出する機能が実装されている
Replay 検出は規定でオフ
有効にするには DetectReplayedTokens 値を true
96
(参考) SAML Artifact Resolution とは
Artifact (アーティファクト)
セキュリティトークン (SAML Assertion) のリファレンス
SSO を実現する トークン受け渡し手順 の 1 つ
① ブラウザーはトークンではなく、トークンの「Artifact」を
STS から受け取り RP にリダイレクトする
② RP は受け取った Artifact を IdP に提示して正当性を評価
③ 評価 OK ならば、RP は IdP から直接トークンを取得する
•
ユーザーとサーバー間の通信帯域が細い場合に有用
STS
97
3
2
1
サービス
6. SAML 2.0
操作モードとプロファイルの一覧
SAML 2.0 の構成要素
プロファイル
アサーション (セキュリティトークン)
承認に必要な情報 (属性)
プロトコル
バインディング
プロトコル
アサーション
IdP/SP/クライアント間のメッセージ送受信の手順
バインディング
リクエストの方法 (Post/Redirect/Artifact/SOAP…)
セキュリティ(SSL/TLS)
プロファイル
プロトコル、バインディング、アサーションの組み合わせ
メタデータ
信頼する IdP や RP に関する情報
エンドポイントと使用可能なバインディング
署名、キー
99
SAML 2.0 操作モード
(SAML 2.0 Operational Mode)
IdP
IdP Lite AD FS 2.0
SP
AD FS 2.0
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
100
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 属性
101
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>
103
相互運用のポイント～属性のフォーマット
• 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 に変更
次のページ参照
104
(参考) 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");
105
相互運用のポイント～クレームの暗号化
(Encryption)
• AD FS 2.0 の場合
• AES-256 を使用
(例) Java の場合 既定値は AES-128
• 対処法
• 相手側も AES-256 を使用する
or
• AD FS 2.0 側で暗号化を無効にする
(set-ADFSRelyingPartyTrust コマンドレット)
106
相互運用のポイント～署名 (Signing)
AD FS 2.0 の場合
規定で SHA-256 を使用する
IdP の場合は アサーション、各種応答、
ログアウト要求
SP の場合 は 認証依頼 (AuthnRequest) 、
ログアウト応答、アーティファクト GET
対処法
AD FS 2.0 側で SHA-1 を使用する
or
相手側も SHA-256 を使用する
107
相互運用のポイント ～ 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 管理ツールでクレーム変換を定義する
108
(参考) 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
109
相互連携のポイント～ 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
110
（ご参考）
クレーム ベースのフェデレーションが実現する
Windows Azure と ID as a Service の連携
Azure 時代の ID 管理と高度認証
株式会社 野村総合研究所
DI ソリューション事業部
AD FS 2.0 と IDaaS の連携例
Windows Azure
WIF
SaaS A
（外部ID受入)
同期
信頼
Azure利用企業
のID管理を代行
WIF
SaaS B
(独自ID/PW発行)
AD FS 2.0
信頼
高度な認証
IDaaS(3 rd
信頼
112
同期
AD FS 2.0
独自
IdP A
IdP B
オンプレミス
ID管理
Party)
国内センタ
Azureアプリの
ID管理を代行
 Azure 上のアプリ開発では、いままで
よりも ID 管理や認証が悩みどころに
 WIF ベースのアプリ開発で、オンプレ
ミス /IDaaS の ID管理・認証を活用
ACS と IDaaS の連携例
•ACS を活用することで、非 WIF ベースの
アプリケーションでも様々な外部 IdP を
利用可能
Windows Azure
SaaS
A
SaaS
B
ACS v2 がでるまでは
IDaaS を信頼
国内センタ
信頼
高度な認証
ACS V2
信頼
信頼
信頼
外部クレーム情報の統合
IDaaS(3 rd Party)
mixi
AD FS 2.0
Yahoo
NTT
IdP A
Facebook
Twitter
オンプレミス
113
Google
複数の外部 IdP と
高度認証との組合せ
and more...
© 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