Cloud で Active Directory を活用するには

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

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

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

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

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

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

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

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

IDM と連携の限界
IDM:Identity Management
認証プロトコルの違い
Identity 管理ポリシーの違い
アプリケーション側の対応
Single Sign-On/Off への適用
Active
Directory
アプリ1
LA空港
日本国
プロトコル
情報の整形
情報の解釈
情報
プロトコル
情報
情報
アプリ2
OpenLDAP
中国
ﾋｰｽﾛｰ
プロトコル
情報の整形
プロトコル
情報の解釈
情報
情報
情報

解決策
フェデレーション信頼による素結合
STS によりアプリケーション側の処理を削減
情報はセキュリティトークンに格納して受け渡し
米政府
STS
STS
Active
Directory
アプリ1
日本国
LA空港
プロトコル
情報の整形
情報の解釈
プロトコル
情報
プロトコル
フェデレーション信頼
情報
情報
ｲｷﾞﾘｽ政府
STS
アプリ2
OpenLDAP
STS
中国
ﾋｰｽﾛｰ
プロトコル
プロトコル
プロトコル
情報の整形
情報の解釈
情報
情報
情報

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

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

SSO を実現するための構成要素
AD DS
認証サーバー
ユーザーを認証し、セキュリティトークンの発行を許可する
AD FS 2.0
STS( セキュリティトークンサービス )
AD認証されたユーザーに対してセキュリティトークンを発行する
アプリケーションにセキュリティトークンを渡す
クレームストア
セキュリティトークンに組み込むユーザー属性が格納されている
AD DS/ldap
SQL Server
WIF
WS-Federation/WS-Trust/SAML 2.0 に対応したアプリケーション
※WIF は SAML2.0 に対応していない

基本的な構成
それぞれの企業にSTSを設置
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

基本的な構成～簡易版
同一企業内であれば STS は1台で構築可能
企業A
RP/SP
IdP/CP
信頼
③アクセス
AD DS
①認証
WIF
AD FS 2.0
Application
②Token発行

アプリケーションがクラウドだったら…
クラウドアプリでも考え方は変わらない
企業A
RP/SP
IdP/CP
信頼
③アクセス
AD DS
①認証
WIF
Application
AD FS 2.0
②Token発行

WIF アプリケーションとSSOの仕組み
クラウド上に Identity 情報を用意せずに、クレームによるアクセス承認が可能
7
WIF
信頼
クラウド
オンプレミス
AD DS
AD FS2.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) を使用してクレームを取り出し、評価する
画面がブラウザーに送られる

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

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

クレームの構造と識別方法
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

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

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

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

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

カスタム規則
テンプレートに用意されていないルールは自作することができる
「要求規則言語」を使用する
条件部
発行部
条件文 1
True
=>
発行文
条件文 2
&&
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つの疑問が…
クラウド上のアプリケーションが
　　　　　　　　社外のものだったら？？？？

クラウドアプリが社外だったら…?
企業B社内のSTSとフェデレーション信頼を構築
企業B
企業A
RP/SP
IdP/CP
WIF
Application
信頼
AD DS
信頼
AD FS 2.0
AD FS 2.0

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

クラウドアプリが社外だったら…?
クラウド上の STS を使用する
企業B
企業A
RP/SP
IdP/CP
STS
REST
Application
信頼
AD DS
AD FS 2.0
AD FS 2.0

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
① 認証
④ 結果

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

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
クライアント

処理の流れ
クライアントアプリケーションが 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 を分解してロールを検証
ロールが正しければサービスを実行

まとめ

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
信頼

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

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

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

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

© 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.

Cloud で Active Directory を活用するには

by Junichi Anno on Sep 11, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Cloud で Active Directory を活用するには — Presentation Transcript