Embed Size (px)
Citation preview
Cloud de Active Directory～シングルサインオンを実現するための処方箋～
マイクロソフト株式会社
エバンジェリスト
安納 順一（あんのう じゅんいち）http://blogs.technet.com/junichia/
本日のテーマ
アプリケーションがクラウドにスケールアウトしたとき、
• 「認証」と「承認」の仕組みはどう変わるのか？
• 既存の Active Directory は生かせるのか？
• 夢のシングルサインオンは可能なのか？
についてお話しします。
企業全体
組織内
組織内
クラウド
ID を使用する環境
自宅
企業全体
企業間
企業：クラウド
アプリケーション在るところ「ID」在り
予測される ID 管理の問題点
• 見えない利用者の ID 管理/認証/承認
• 異なる認証方式の相互運用
• ディレクトリサービスの設置が困難
クレームベース セキュリティフェデレーション セキュリティ モデル
健保番号/免許証番号/住民票
入国
日本国政府
(例) 入国審査
出国
発行
パスポート• 発行国• 氏名• 有効期限• 旅券番号• 写真• 出国印
米国政府
本人• 顔• 指紋
入国申請書• 滞在期間• 滞在先
パスポート・・
空港
信頼
ビザ• 滞在可能期間
信頼
入国
日本国政府
フェデレーション セキュリティ モデル
出国
発行
パスポート• 発行国• 氏名• 有効期限• 旅券番号• 写真• 出国印
米国政府
本人• 顔• 指紋
入国申請書• 滞在期間• 滞在先
パスポート・・
健保番号/免許証番号/住民票
信頼
ビザ• 滞在期間
クレームプロバイダー
クレームクレームクレームクレームクレームクレーム
資格情報
セキュリティトークン
オーソリティ
リライングパーティ
クレームクレーム
クレーム
クレームクレーム
クレーム署名
サブジェクト
空港
信頼
リソース
クレーム（主張）とは
• アプリケーションに渡すユーザー自身の属性
• 承認に使用される
セキュリティ トークン
• パッケージ化されたクレーム
• 発行者の署名によって信頼性を担保
• STS ( Security Token Service ) が生成する
セキュリティトークン
IDM と連携の限界
• 認証プロトコルの違い• Identity 管理ポリシーの違い• アプリケーション側の対応• Single Sign-On/Off への適用
IDM : Identity Management
Active Directory
プロトコル
アプリ1
プロトコル
情報の整形
OpenLDAP
プロトコル
情報の解釈
アプリ2
プロトコル
情報の解釈
情報の整形
情報
情報
情報
LA空港日本国
ﾋｰｽﾛｰ中国
解決策• フェデレーション信頼による素結合• STS によりアプリケーション側の処理を削減• 情報はセキュリティトークンに格納して受け渡し
STSSTS
STSSTS
Active Directory
プロトコル
アプリ1
プロトコル
情報の整形
OpenLDAP
プロトコル
情報の解釈
アプリ2
プロトコル
情報の整形
情報の解釈
情報
情報
情報
プロトコル
プロトコル
フェデレーション信頼
LA空港日本国米政府
中国 ﾋｰｽﾛｰ
ｲｷﾞﾘｽ政府
フェデレーションセキュリティモデル
STS
STSActive Directory
プロトコル
アプリ1
プロトコル
情報の整形
情報の解釈
情報
プロトコル
Active Directory Federation ServiceActive Directory Federation Service
2.0
Windows Identity Foundation
信頼
• AD FS 2.0 がユーザーのロールを管理• アプリケーションは受け取ったロールを解釈するだけ
認証/ロール管理からの分離
アプリケーション
アプリケーション
アプリケーション
これまでの方式
クレームに対応
SSO を実現するための構成要素
認証サーバー• ユーザーを認証し、セキュリティトークンの発
行を許可する
STS( セキュリティトークンサービス )• AD認証されたユーザーに対してセキュリティトーク
ンを発行する• アプリケーションにセキュリティトークンを渡す
クレームストア• セキュリティトークンに組み込むユーザー属性
が格納されている
AD DS
AD FS 2.0
AD DS/ldapSQL Server
WS-Federation/WS-Trust/SAML 2.0 に対応したアプリケーション※WIF は SAML 2.0 に対応していない
WIF
基本的な構成
IdP/CP
AD DS
クレームストア
AD FS 2.0
RP/SP
Application
信頼
AD FS 2.0
IdP：Identity ProviderCP：Claims ProviderRP : Relying PartySP : Service Provider
企業A 企業B
• それぞれの企業にSTSを設置• STS 間でフェデレーション信頼を構築
②Token
発行
WIF
基本的な構成～簡易版
IdP/CP
AD DS
クレームストア
AD FS 2.0
RP/SP
Application
信頼
企業A
• 同一企業内であれば STS は1台で構築可能
②Token
発行
WIF
アプリケーションがクラウドだったら…
IdP/CP
AD DS
クレームストア
AD FS 2.0
RP/SP
信頼
企業A
• クラウドアプリでも考え方は変わらない
Application
②Token
発行
WIF
WIF アプリケーションとSSOの仕組み
オンプレミス
クラウド
AD DS AD FS 2.0
12
3
4
クラウド上に Identity 情報を用意せずに、クレームによるアクセス承認が可能
WIF
5
6
7
8
WIF：Windows Identity Foundation
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. 画面がブラウザーに送られる
ブラウザー
WIF アプリケーションの構造• WIF (Windows Identity Foundation) を使用して
セキュリティー トークンからクレームを取り出す
• WIF は WS-Federation/WS-Trust をサポート
ASP.NET
Windows Identity Foundation
.NET Framework 4
AD FS 2.0クレームの評価
ロール判定
各種処理
ロールは既にトークンにセットされているので評価するだけでOK
RP/SPIdP/CP
「信頼」とは？
信頼 MetadataMetadata
URI URI
精神的には
IdP 側 の Identity/Role 管理責任を信頼
RP 側の クレーム管理責任を信頼
物理的には
メタデータ/証明書/暗号化キーを事前に交換
お互いの「すり替わり」を防止
データの横取りを防止
クレームの構造と識別方法
Claims
Claim ClaimType
Value
Issuer
OriginalIssuer
ValueType
これらの値でクレームを識別する
subject
Claim
Claim
Claim
Microsoft.IdentityModel.Claimshttp://msdn.microsoft.com/ja-jp/library/microsoft.identitymodel.claims.aspx
アプリケーション作成時の留意点
• 空の属性はクレームに含まれない– ゆえにトークンにも含まれない
– 安易に「既定値」を使用するととんでもないことに!
氏名 = 安納 順一
会社名 = マイクロソフト株式会社
役職＝ (空)
IdP
RP 氏名 = 安納 順一
会社名 = マイクロソフト株式会社
サポートされているプロトコルとトークン形式
• パッシブ SAML WebSSO
– SAML 2.0 トークン
• パッシブ WS-Federation
– SAML 1.1 トークン
• アクティブ WS-Trust(CardSpace 対応含む)
– SAML 2.0 トークン
– SAML 1.1 トークン
AD FS 2.0 WIF
AD FS 2.0 ～クレーム パイプライン
要求プロバイダー信頼(Claims Provider Trusts) 証明書利用者信頼 (Relying Party)
証明書利用者(RP)
① 受付ける ③ 発行する
発行変換規則
input
output
受け付け変換規則
input
output発行承認規則
input
output
② 承認する
クレームストア
OK/NG
switch
トークン
要求規則 (Claim Rule)
要求規則 の処理プロセス
要求規則1
要求規則2
要求規則セット
Input Claim Set
OutputClaim Set
クレーム
条件 発行
トークン
要求規則 n
テンプレートが用意されている
カスタム規則
• テンプレートに用意されていないルールは自作することができる
• 「要求規則言語」を使用する
入力方向のクレーム/属性をチェックし、すべての条件が True の場合に「発行部」が実行される。条件部が無い場合には無条件で True とみなされる。
=>True
False
発行するトークンタイプと、そこに格納する属性/値を指定する。必須
条件部条件文 1
条件文 2&&
&&
オプション
発行部
発行文
条件部
発行部
カスタム規則の書式 (例)
<変数>:[ <クレームの属性> == <値> ] => issue ( <発行書式> );
c:[type == “http://schemas.xx.org/claims/Email”] => issue (claim = c) ;
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);
パス スルー (入力クレームをそのまま出力クレームに転送)
ユーザー名で AD DS を検索して会社名を取り出す
ここで1つの疑問が…
クラウド上のアプリケーションが
社外のものだったら？？？？
クラウドアプリが社外だったら…?
IdP/CP
AD DS
クレームストア
AD FS 2.0
RP/SP
信頼
企業A
• 企業B社内のSTSとフェデレーション信頼を構築
Application
企業B
AD FS 2.0
WIF
アプリケーションが RESTful ならば
こんな方法もあります
クラウドアプリが社外だったら…?
IdP/CP
AD DS
クレームストア
AD FS 2.0
RP/SP
企業A
• クラウド上の STS を使用する
Application
企業B
AD FS 2.0
STS
REST
platform
AppFabricAccess Control Service
Windows Azure platform
AppFabric Access Control Service V1
• RESTful サービスに特化したシンプルな RP/SP 用 STS– プロトコル ：OAuth WRAP
– トークン ：SAML 1.1,SAML 2.0,SWT
信頼
Relying P
arty
Service Bus
信頼
STS
REST
AppFabric ACS V1 の想定シナリオ
道路の混雑状況を提供するサービスREST API
企業Ａ 企業C
企業B
Request
Request
Resp
onse
Resp
onse
Application Application
RESTful なサービスへのアクセス制御を行う
クライアントアプリケーション
ACS を 企業内 AD との SSO に使用する
オンプレミス
クラウド
AD DS
2
ACS では Passive SSO がサポートされていないことに注意
AD FS 2.0
ACSRESTService
信頼
信頼
13
4
5
68
9
7
10
WS-Trust
WRAP
処理の流れ
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.ロールが正しければサービスを実行
まとめ
3 種類の STS(Security Token Service)• STS により「使用目的」と「出来ること」が異なる
MFG：Microsoft Federation GatewayACS : Windows Azure platform AppFabric Access Control Service
【 MFG 】
MFG
AD FS 2.0
Microsoft Online Services用に用意された STS
【 AD FS 2.0 】
AD FS
2.0
高機能な STSオンプレミスに配備
AD FS 2.0anyIdPs
【 ACS V1 】
ACS
anyIdPs
クラウド上に用意された STS
AD FS 2.0
信頼
STS (Security Token Service) の役割• セキュリティトークンの発行と管理
• クラウド アプリケーションとオンプレミスの架け橋
STS
STS
信頼信頼
信頼信頼
AD DS AD FS
ACS
AD FS 2.0 と ACS V1 の違い
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 ○ ×
管理方法 • 管理コンソール• Windows PowerShell
• ACM.exe コマンド• ACSM Browser
アプリケーションに WIF は必要か?
必要 必要ない
IdP の選択 ○ 選択ページのカスタマイズも可能
× クライアントアプリケーションが IdP を意識する
ACS V1 は AD FS 2.0 の替わりにはなれないことに注意
IdPとの連携が必要
シナリオによって使用するSTSが異なる
IdP/CP RP/SP
クラウド
オンプレミス
REST
WIF
AD FS 2.0
ACS V1
AD DS
REST
WIF
AD FS 2.0
ACS V2 はAD FS 2.0 以外の IdP にも対応予定
IdP/CP RP/SP
クラウド
オンプレミス
REST
WIF
AD FS 2.0
ACS V2
AD DS
REST
WIF
AD FS 2.0
ACS V2 が万能になるわけではありません！
© 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.
