マイクロソフト株式会社 - PowerPoint Presentation

Slide1

Slide2

マイクロソフト株式会社デベロッパー & プラットフォーム統括本部エバンジェリスト安納 順一 (あんのう じゅんいち)

AD FS 2.0 のアーキテクチャとWindows Azure 連携の実装～ AD FS 2.0 によるシングル サインオンの実現 2 ～

セッション

ID

：

T3-304

Slide3

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

の基礎知識

Slide4

開発担当インフラ担当

Identity はハイブリッドなテクノロジアーキテクチャが両者に影響両者の「架け橋」となる役割が必要

Identity

コード

テスト

仕様変更

設計

構築

管理

Slide5

混乱していませんか？

Windows

Live ID

Microsoft Federation Gateway

AppFabric

Access Control Service

Active Directory

Federation Service

Active

Directory

STS

STS

STS

ココをお話しします

platform

T1-304

T3-304

Slide6

セッションの目的とゴールSession Objectives and Takeawaysセッションの目的以下のテクノロジに関する解説とデモンストレーションAD FS 2.0 のアーキテクチャ

AD FS 2.0 を使用した クラウド アプリケーションとの SSO AD FS 2.0 と AppFabric ACS との相互運用AD FS 2.0

と

他社製品

との相互運用

セッションのゴール

[

クラウド

]

＋

[Identity]

案件における

アーキテクチャ決定

に必要な事項を理解し、

適切な設計と構築が行える。

または、指示を与えることができるようになる。

Slide7

アジェンダ第 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 の仕様を理解し、他ベンダーの製品やサービスとの相互運用性の可能性について理解しましょう

Slide8

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

Slide9

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

STS

STS

信頼

信頼

信頼

信頼

トークン

トークン

アクセス

アクセス

信頼できるかどうかはそれぞれのアーキテクチャに依存する

AD DS

AD FS

ACS

Slide10

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

any

IdPs

【

ACS

】

ACS

any

IdPs

クラウド上に

用意された

STS

AD FS 2.0

信頼

T1-304

Slide11

WIF

アプリケーションとの連携

オンプレミス

クラウド

AD DS

AD FS

2.0

信頼

1

2

3

4

クラウド上に

Identity

情報を用意

せずに

、

クレームによるアクセス承認が可能

WIF

5

6

7

8

WIF

：

Windows Identity Foundation

Slide12

WS-Federation (Passive SSO) の流れオンプレミスの AD DS にログオン依頼AD DS からクレデンシャルが送信されクライアントに保存------------Windows Azure 上のアプリケーションにアクセスクレーム ポリシーをアプリケーションから受け取り、STS (AD FS 2.0) にリダイレクト属性ストアである

AD DS からクレームを収集集めたクレームに署名をしてセキュリティトークンを生成し、Windows Azure アプリケーションに送信アプリケーションはセキュリティトークンを受け取り、Windows Identity Foundation (WIF) を使用してクレームを取り出し、評価する画面がブラウザーに送られる

Slide13

オンプレミスクラウド

AD DSAD FS 2.0

信頼

WIF

WIF

：

Windows Identity Foundation

ITPRO

の方へ

開発者に渡すべき情報は何なのか？について理解しましょう

トークン

アクセス

Slide14

RP/SPIdP/CP

「信頼」とは？

信頼

Metadata

Metadata

URI

URI

精神的には

IdP

側 の

Identity/Role

管理責任を信頼

RP

側の クレーム管理責任を信頼

物理的には

メタデータ

/

証明書

/

暗号化

キーを

事前に

交換

お互いの「すり替わり」を防止

データの横取りを防止

Slide15

ブラウザー

WIF

アプリケーションの構造

WIF (Windows Identity Foundation)

を使用して

セキュリティー トークンからクレームを取り出す

WIF

は

WS-Federation/WS-Trust

をサポート

ASP.NET

Windows Identity Foundation

.NET Framework 4

トークン

AD FS 2.0

クレームの評価

ロール判定

各種処理

ロールは既にトークンに

セットされているので

評価するだけで

OK

Slide16

クレームの構造と識別方法ClaimsClaim

ClaimType

Value

Issuer

OriginalIssuer

ValueType

これらの値で

クレームを識別する

subject

Claim

Claim

Claim

Microsoft.IdentityModel.Claims

http://

msdn.microsoft.com/ja-jp/library/microsoft.identitymodel.claims.aspx

Slide17

アプリケーション作成時の留意点空の属性はクレームに含まれないゆえにトークンにも含まれない安易に「既定値」を使用するととんでもないことに!氏名 = 安納

順一会社名 = マイクロソフト株式会社

役職＝

(

空

)

IdP

RP

氏名

=

安納

順一

会社名

=

マイクロソフト

株式会社

Slide18

オンプレミスクラウド

AD DSAD FS 2.0

信頼

WIF

WIF

：

Windows Identity Foundation

Dev

の方へ

AD FS

からどこまで精度の高い情報が得られるのかを理解しましょう

Slide19

用語について基本的に、日本語 UI に沿った用語を使用します。が…ちょっとアレなところもあるので、以下の対応票を参考にしてください。

日本語対応する英語要求Claim, クレーム

規則

Rule,

ルール

要求の種類

Claim Type,

クレームタイプ

要求記述

Claim Description,

クレームディスクリプション

要求 プロバイダー

Claims Provider,

クレーム プロバイダー

証明書利用者

Relying Party,

リライング パーティ

発行承認規則

Issuance Authorization Rules

受付変換規則

Acceptance Transform Rules

発行変換規則

Issuance Transform

Rules

Slide20

AD FS 2.0 ～クレーム パイプライン要求プロバイダー信頼(Claims Provider Trusts)

証明書利用者信頼 (Relying Party)

証明書利用者

(RP

)

① 受付ける

③ 発行する

発行

変換

規則

input

output

受け

付け

変換

規則

input

output

発行

承認

規則

input

output

② 承認する

要求プロバイダー

/

属性ストア

OK/

NG

switch

トークン

要求規則

(Claim Rule)

Slide21

要求規則 (Claim Rule)入力された情報をルール (規則) に沿って処理し出力する処理されたクレームは既定のパイプラインを通る

メンバーシップ入力方向の要求カスタム クレーム

他の要求

プロバイダー

LDAP

属性

スルー

変換

フィルター

AD DS

AD

LDS

LDAP

出力

SQL Server

その他

要求規則

Slide22

要求規則 の処理プロセス

要求規則1

要求規則

2

要求規則セット

Input Claim Set

Output

Claim Set

クレーム

条件

発行

トークン

要求規則

n

Slide23

要求規則テンプレート要求規則を作成するためのテンプレート作成した要求規則は1つの IdP/RP にのみ関連付けられる[LDAP 属性を要求として送信]

[グループ メンバーシップを要求として送信][入力方向の要求を変換]

[

入力方向の要求をパススルーまたはフィルター処理

]

[

カスタム規則を使用して要求を送信

]

[

入力方向の要求に基づいてユーザーを許可または拒否

]

[

すべてのユーザーを許可

]

Slide24

カスタム規則の定義テンプレートに用意されていないルールは自作することができる「要求規則言語」を使用する入力方向のクレーム/属性をチェックし、すべての条件が True

の場合に「発行部」が実行される。条件部が無い場合には無条件で True とみなされる。

=>

True

False

発行

するトークンタイプと、

そこに格納する属性

/

値を指定する。

必須

条件部

条件文

1

条件文

2

&&

&&

オプション

発行部

発行文

条件部

発行部

Slide25

カスタム規則の書式 (例)<変数>:[ <クレームの属性> == <値> ]

=> 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

を検索して会社名を取り出す

Slide26

第 1 章のまとめAD FS 2.0 を使用すると【利用者】オンプレミスの Identity

でクラウド上のアプリケーションに Single Sign-On できる【ITPRO】クラウド アプリ用の Identity を個別に管理する必要が無い

　　

※

今まで

通り

Active Directory

で

!

【

開発者

】

アプリケーションは

ID

/

ロール

管理から解放

されるため、

Identity

関連のビジネス ロジック変更に影響を受けない

企業間の相互運用にも

AD FS 2.0

Slide27

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

つの STS

Slide28

Windows Azure platformAppFabric Access Control Service V1RESTful サービスに特化したシンプルな RP/SP 用 STSプロトコル ：OAuth WRAPトークン ：

SAML 1.1,SAML 2.0,SWT 道路の混雑状況を提供するサービスユーザー

アプリ

問合せ

返答

ユーザー

アプリ

問合せ

返答

Slide29

platform AppFabric

Access Control Service

Windows Azure platform

AppFabric

Access Control

Service

V1

RESTful

サービス

に特化したシンプルな

RP/SP

用

STSプロトコル ：OAuth WRAPトークン

：SAML 1.1,SAML 2.0,SWT

②トークン

① 認証

信頼

④ 結果

セキュリティ キー

or

SAML

1.1/2.0

トークン

or

SWT

③ トークン

Relying Party

Service Bus

信頼

STS

REST

Slide30

AD FS 2.0 と ACS V1 の違いAD FS 2.0ACS V1プロトコル

SAML 2.0WS-FederationWS-TrustOAuth 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 を意識する

AD FS 2.0

の替わりにはなれないことに注意

Slide31

クライアントアプリケーションACS を 企業内

AD との SSO に使用するオンプレミスクラウド

AD DS

2

ACS

では

Passive SSO

がサポートされていないことに注意

AD FS

2.0

ACS

REST

Service

信頼

信頼

1

3

4

5

6

8

9

7

10

WS-Trust

WRAP

Slide32

処理の流れクライアント アプリケーションが 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

を分解してロールを検証

ロールが正しければサービスを実行

Slide33

ACS のトークン発行条件 (認証) セキュリティ キーAD FS 2.0 SAML 1.1/2.0

トークンSWTPOST /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…>

Slide34

RP/SPApplication

REST ServiceIdP

/CP

AD FS

2.0

AD DS

ACS

の構成情報

Namespace

AppFabric

ACS

Scope

Rule

Key

Issuer

InClaim

OutClaim

信頼

信頼

SAML 1.1/2.0

トークン

SWT

クライアント

アプリケーション

Slide35

SWT ～ Simple Web TokenACS から発行されたトークンは検証後、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

Claim n

Issure

Audience

ExpiresOn

HMACHA256

Key

Hash

Slide36

アプリケーション側の対応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

HTTP

Authorization

ヘッダー

からクレームを直接取り出す

ロール

を

検証しクライアント アプリケーションに

アクセス許可を与える

クライアント アプリケーション

REST

サービス

AD FS 2.0

REST

サービス

Slide37

第 2 章のまとめクラウド上に用意された STS (ACS) により、

[オンプレミス]-[クラウド] のフェデレーションを実現ACS は発展中です

現時点で

AD FS

2.0

とのフェデレーションが可能

V2

でサポート予定の機能

主要

IdP

とのフェデレーション信頼

AD FS 2.0

（対応済）

Live

ID,

Facebook,Yahoo

!,

Google

主要プロトコルの実装WS-Trust

,

WS-Federation

OpenID

IdP

の選択画面と

そのカスタマイズ

Passive SSO

には

未対応

Slide38

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

Slide39

相互運用性 を考えるにあたり属性ストア

STSSTS

サービス

サービス

認証サービス

IdP

/CP

RP/SP

「相互運用」する箇所を明確にする

プロトコル

トークン形式

プロトコル

トークン形式

プロトコル

/

トークン形式

API

STS

の仕様

サービス

API

API

Slide40

相互運用の例AD DSAD FS 2.0

OpenID Provider (OP)Azure App

ACS

Azure App

AD FS

MFG+

WLID

MSO

Shibboleth

OpenID

RP

SAML 2.0

対応製品

OpenLDAP

WS-Fed.

SAML

2.0

WS-Trust

OAuth

WRAP

WLID

MFG

SAML 2.0

対応製品

IIS

WIF

OAuth

OpenID

IdP

/CP

RP/SP

プロトコルとトークンが一致していても、

相互運用には連携相手の「意向

(

戦略

)

」による

(

場合がある

)

MSO: Microsoft Online Services

実装済

予定

Slide41

用語の違い AD FS 2.0SAML 2.0 Security Tokenセキュリティトークン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

と呼んでいた

Slide42

SAML 2.0 対応製品との相互運用性AD FS 2.0 をサポートしている OSWindows Server 2008/R2検証済み SAML 2.0 相互運用性パートナーEntrust IdentityGuard Federation Module 9.2, GetAccess 8.0IBM Tivoli Federated Identity Manager (TFIM) 6.2Novell Access Manager 3.1 Ping Identity PingFederate v6.1SAP

NetWeaver Identity Management 7.2Siemens DirX Access V8.1AD FS 2.0 がサポートする SAML 2.0 操作モードIdP Lite, SP Lite, eGov Profile 1.5

重要

Slide43

プロファイル機能IdPIdP

Lite SP SP Lite

ECP

Web

ブラウザー

ー

SSO

AuthnRequest

必須

必須

必須

必須

－

POST

必須

必須

必須

必須

－

アーティーファクト

必須

必須

必須

必須

－

アーティファクトの

解決

SOAP

必須

必須

必須

必須

－

Enhanced

Client/Proxy

PAOS

必須

必須

必須

必須

必須

主体名の識別子の管理

必須

禁止

必須

禁止

－

主体名の識別子

のマッピング

必須

禁止

必須

禁止

－

シングル ログアウト

リダイレクト

必須

必須

必須

必須

－

SOAP

必須

選択

必須

選択

－

IdP

検出

Cookie

必須

必須

選択

選択

－

Furnish/process

Metadata

選択

選択

選択

選択

－

SAML

2.0

プロファイルと操作モード

～

OASIS

Criteria

ADFS2

ADFS2

Slide44

相互運用のポイントMetadata の考慮属性のフォーマットName IDクレームの暗号化署名CRL のチェック

今回はここを見てみましょう

Appendix

を

ご覧ください

Slide45

相互運用のポイント～ MetadataAD FS 2.0

の場合Metadata には WS-Trust/WS-Federation に関する記述が存在する

パートナー側

へ

の読み込み時にエラーとなることがある

対処法

WS-Trust/WS-Federation

に関する記載を

削除する

<

RoleDescriptor

xsi:type

="

fed:ApplicationServiceType

“

~

</

RoleDescriptor

>

<

RoleDescriptor

xsi:type

="

fed:SecurityTokenServiceType

”

~

</

RoleDescriptor

>

Slide46

(参考) 相互運用性 Step by Step ガイドCA Federation Manager Oracle Identity FederationAD FS 2.0以下の製品との相互運用性ドキュメントが

Step By Step として公開済Microsoft ダウンロード センターで検索

※

近日、学術情報フェデレーション

(Shibboleth 2)

との

　相互運用性ドキュメントを公開予定

Slide47

第 3 章のまとめ[ SAML 対応 !] という表記は互換性の担保ではありません

AD FS 2.0 は他社製品との [ フェデレーション信頼 ] が可能です。ただし

…

Metadata

の修正等 細かな対応が必要な場合があります。

大人の階段を上るには「たった

1

回の実証実験」が重要

Slide48

まとめ

Slide49

まとめマイクロソフトの重点課題です「知っていること」＝=「強み」です「知っている人」がプロジェクトを操れます

Interoperability は、

AD

FS

2.0

Windows Azure

AppFabric

Access Control Service

Microsoft Federation

Gateway

3

つの

テクノロジの進化が

ハイブリッド環境

を支えます

シングル サインオン実現の「カギ」は信頼関係です

まずは社内ディレクトリ サービスの整備から

Slide50

関連セッションT1-304 Day1 15:20 ～ 16:30 次期 Microsoft Online Services の ID およびアクセス管理～ AD FS 2.0 によるシングル サインオンの実現 1 ～ T3-302 Day3 16:50 ～

18:00ポリシー ベースで ID 管理を実現する!～ Forefront Identity Manager 2010 実践的構築手法 ～T1-404 Day2 15:20 ～ 16:30Windows Azure platform AppFabric サービス バスにおける設計パターン、ベスト プラクティスおよびテクニック

インフラ

開発

開発

インフラ

BOF-09

Day3

10:55

～

12:05

Silverlight

と

WIF (Windows Identity Foundation)

の

アプリケーション

連携

開発

開発

インフラ

インフラ

終了御礼

終了御礼

Slide51

参考サイトInternet2 Microsoft Interop (英語)https://spaces.internet2.edu/display/SHIB2/MicrosoftInteropスピーカー (安納 順一) の Bloghttp://blogs.technet.com/junichia/Active Directory TechCenterhttp://technet.microsoft.com/ja-jp/activedirectory/default.aspx

@IT Windowsで構築する、クラウド・サービスと社内システムのSSO環境http://www.atmarkit.co.jp/fwin2k/operation/adsf2sso01/adsf2sso01_01.htmlGeneva Team Bloghttp://blogs.msdn.com/b/card/TechDays 2010 T4-401オンプレミス &

クラウドにおける

Identity

連携の

全体像

http

://www.microsoft.com/japan/events/techdays/2010

/

Slide52

ご清聴ありがとうございました！セッション IDT3-304

アンケートにご協力ください

Slide53

復習 : 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 の連携

Appendix

Slide54

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

Slide55

クラウド

ID

を使用する環境

自宅

　

企業全体

企業全体

組織内

企業間

企業：クラウド

企業：クラウド

アプリケーション在るところ「

ID

」在り

組織内

組織間

Slide56

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

Slide57

自宅■環境PC スタンドアロンアプリケーション

はローカル■課題1 台の

PC

を家族で共有

■解決策

ユーザー

ID

を

PC

に登録

共有

PC

Slide58

組織内■環境ファイル サーバーをデータ格納庫として使用■課題

増え続けるユーザーの管理リソース増加と複雑化するアクセス権の管理■解決策

ディレクトリ サービスの導入

DS

DS

：

Directory Service

Slide59

企業全体①■環境複数のアプリケーション サーバー

分散したディレクトリ サービス■課題ID

と

パスワード

の統一

■解決策

メタディレクトリ システムによる同期

Metadata

HR

DS

DS

Mail

ユーザー

DB

LOB

LOB

メタディレクトリ サーバー

Slide60

企業全体②■環境重要

な情報を扱うアプリケーション■課題より強力な認証による資格情報の識別

■解決策

証明書による認証

/

承認

ルート認証局

中間認証局

DS

Slide61

企業全体③－組織間

■環境他部門サーバーへのアクセス■課題

他部門ユーザーの

ID

管理

/

認証

/

承認

■解決策

クレームベースのセキュリティ

DS

信頼

STS

DS

組織

A

組織

B

LOB

STS

：

Security Token Service

Slide62

企業間■環境

企業間のアプリケーション共有■課題社外ユーザーの ID

管理

/

認証

/

承認

企業間のセキュリティ ポリシーの

整合性

■解決策

フェデレーション ＋ クレームベース

企業

A

企業

B

STS

STS

DS

信頼

Slide63

企業 A

DS

企業

-

クラウド

■環境

クラウド アプリケーションの

社内利用

■課題

社内とクラウドの認証統合

利用者の

ID /

素性管理

■解決策

フェデレーション ＋ クレームベース

クラウド

信頼

STS

STS

Slide64

予測される ID 管理の問題点見えない利用者の ID 管理/認証/承認異なる認証方式の相互運用

クレームベース セキュリティフェデレーション セキュリティ モデル

Slide65

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

Slide66

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

INITIATIVE による相互運用性テストをパス

Slide67

AD FS 2.0 の目的誰が？どこに？アクセスできるのか？

どんな「役割」で？を明確にしてサービスに渡すこと

Identity

ビジネス ロジックの

可視化

結果として

SSO

が容易になる

どの

機能に？

Slide68

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

1.1 トークン

Slide69

WS-Federation による相互運用性AD FS v1.x をサポートしている OSWindows Server 2003 R2Windows Server 2008/R2WS-Federation 相互運用パートナーIBM Tivoli Federated Identity ManagerCA eTrust Siteminder 6 SP5Oracle Identity FederationPing Identity PingFederateNovell Access Manager 3.1Shibboleth System 1.3Sun OpenSSO Enterprise

Slide70

SAML 2.0 製品との相互運用性AD FS 2.0 をサポートしている OSWindows Server 2008/R2検証済み SAML 2.0 相互運用性パートナーEntrust IdentityGuard Federation Module 9.2, GetAccess 8.0IBM Tivoli Federated Identity Manager (TFIM) 6.2Novell Access Manager 3.1 Ping Identity PingFederate v6.1SAP

NetWeaver Identity Management 7.2Siemens DirX Access V8.1AD FS 2.0 がサポートする SAML 2.0 操作モードIdP Lite, SP Lite, eGov Profile 1.5

Slide71

AD FS の役割 ①IdP - RP フェデレーション信頼 の確立クレームの収集とトークンの発行コードレス

AD FSID 管理

サービス

ロール管理

(

クレーム フロー

)

ロール判定

認証

トークン

処理

本体

アプリケーション

クレーム

信頼

ユーザー

ID

部署

役職

Slide72

AD FS の役割 ②組織/企業間のセキュリティ トークンのゲートウェイサービスに合った形式に変換

AD FSor any STS

ロール判定

トークン

処理

本体

アプリケーション

信頼

AD FS

or any STS

トークン

トークン

信頼

認証

クレーム

トークン

企業

/

組織の壁

変換

収集

企業

A

企業

B

Slide73

クレームとはユーザーについての詳細情報承認に使用されるユーザー ID

パスワード資格情報（認証結果）

メール アドレス

役職

年齢

所属部門

性別

住所

年収

所属企業

言語

Slide74

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

クレーム 1

クレーム

2

クレーム

n

署名

クレームの

発行元による

Slide75

IdPクレームベースの認証

ユーザーSTS

①信頼

ID

ストア

アプリケーション

アプリケーションが

IdP

を信頼することで、

直接認証を行わない

(ID

管理の必要が無い

)

承認

に必要

な情報をクレームから取り出す

アプリケーションはクレームを理解しなければならない

②アクセス

③ポリシー取得

④認証

/

トークン要求

⑥ｾｷｭﾘﾃｨﾄｰｸﾝ

⑥ｾｷｭﾘﾃｨﾄｰｸﾝ

⑤ｸﾚｰﾑ収集

ID library

IdP

：

Identity

Provider

Slide76

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

Slide77

セキュリティトークンサービスと認証/ロール

管理の分離アプリケーション

認証

ロール

サービス

アプリケーション

認証

ロール

サービス

アプリケーション

サービス

認証

クレーム

クレーム

認証

認証

クレーム解釈

Slide78

要求元要求元

組織間でクレームを使うには発行元が要求元に信頼されている要求元は複数の発行元を信頼しうる

条件

1

：カードは

クレジットカード会社により証明

条件

2

：店舗はクレジットカード

会社

を信頼

∴買い物が可能

条件

1

：パスポートは日本国

に

より証明

条件

2

：諸外国は日本

国

を信頼

∴入国可能

発行元

要求元

信頼

フェデレーション セキュリティ モデル

Slide79

入国

日本国政府

(

例

)

入国審査

出国

発行

パスポート

発行国

氏名

有効期限

旅券番号

写真

出国印

米国政府

本人

顔

指紋

入国申請書

滞在期間

滞在先

パスポート

・

・

健保番号

/

免許証番号

/

住民票

空港

信頼

ビザ

滞在可能期間

信頼

Slide80

入国

日本国政府

フェデレーション セキュリティ モデル

出国

発行

パスポート

発行国

氏名

有効期限

旅券番号

写真

出国印

米国政府

本人

顔

指紋

入国申請書

滞在期間

滞在先

パスポート

・

・

健保番号

/

免許証番号

/

住民票

信頼

ビザ

滞在期間

アイデンティティ

プロバイダー

クレーム

クレーム

クレーム

クレーム

クレーム

クレーム

資格情報

セキュリティ

トークン

オーソリティ

リライング

パーティ

クレーム

クレーム

クレーム

クレーム

クレーム

クレーム

署名

サブジェクト

空港

信頼

リソース

Slide81

アイデンティティ

プロバイダーフェデレーションによる Passive SSO 手順

ユーザー

STS

リライング

パーティ

STS

Application

信頼

信頼

ID

ストア

１

2

3

4

5

6

ID library

７

Slide82

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

Application アクセスに必要なトークンを要求Application アクセスに必要なトークン取得ID Library にトークンを渡す

ID Library

はトークンを解析しクレームを取得

Slide83

マイクロソフト テクノロジに置き換えると

ADFS 2.0企業

B

Application

信頼

信頼

Active Directory

3

WIF

７

企業

A

ADFS

2.0

事前に認証し

資格情報

を

取得

資格情報

を確認

ユーザー

WIF

：

Windows Identity Framework

6

5

4

2

１

Slide84

企業 B

ADFS と他社 STS の相互運用他社 STS

信頼

ID Store

企業

C

Application

信頼

WIF

ADFS

2.0

他社

STS

信頼

Application

ADFS

2.0

Active Directory

信頼

Slide85

Windows CardSpaceトークン発行プロセスの安全性向上フィッシング防止マネージド カード (IdP が発行したカード) と個人用 カードマネージド カードには個人情報は含まれない

IdP

RP

①アクセスすると

　カード セレクター

　が開く

②カードを選択

　すると

IdP

に

　転送される

CardSpace

を使用するようにコーディングされている

③トークンが

　発行される

カードには

IdP

の情報が書かれている

Slide86

マッサージ店

予約サイトCardSpace

個人用カードの用途

自分自身が

IdP

クレームは自分で用意する

地域

新宿西口

予約年月日

2010

年

3

月

1

日

予約時間

17:00~18:00

カードを選択するとトークンが生成されて

RP

に送信

Slide87

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

Slide88

要求規則セット (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

で実装する。

Slide89

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

Slide90

既定のクレーム タイプ英語表記日本語表記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

認証方法

Slide91

英語表記日本語表記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

認証タイム スタンプ

Slide92

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

Slide93

既定の LDAP 属性LDAP 属性CompanyDepartmentDisplay-Name

E-Mail-AddressEmployee-IDEmployee-NumberEmployee-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

これ以外の

ldap

属性を使用する場合には「カスタム規則」を使用

Slide94

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

Slide95

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

可用性

低

高

プライマリ

セカンダリ

セカンダリ

R/O

R/O

R/W

ADFS

ADFS

ADFS

ADFS

ADFS

ADFS

R/W

SQL Server

Slide96

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

値を true http://msdn.microsoft.com/en-us/library/ee517257.aspx

Slide97

(参考) SAML Artifact Resolution とはSSO を実現する トークン受け渡し手順 の 1 つブラウザーはトークンではなく、トークンの「Artifact」を STS から受け取り RP にリダイレクトするRP は受け取った Artifact を IdP に提示して正当性を評価評価

OK ならば、RP は IdP から直接トークンを取得するユーザーとサーバー間の通信帯域が細い場合に有用

Artifact (

アーティファクト

)

セキュリティトークン

(SAML Assertion)

の

リファレンス

1

2

3

STS

サービス

Slide98

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

Slide99

SAML 2.0 の構成要素 アサーション (セキュリティトークン)承認に必要な情報 (属性)プロトコルIdP/SP/クライアント間のメッセージ送受信の手順バインディングリクエストの方法 (Post/Redirect/Artifact/SOAP…)セキュリティ(SSL/TLS)プロファイル

プロトコル、バインディング、アサーションの組み合わせメタデータ信頼する IdP や RP に関する情報エンドポイントと使用可能なバインディング署名、キー

プロファイル

バインディング

プロトコル

アサーション

Slide100

SAML 2.0 操作モード(SAML 2.0 Operational Mode)IdPIdP LiteSPSP LiteIdP ExtendedSP ExtendedEnhanced Client/Proxy (ECP)SAML Attribute AuthoritySAML Authorization Decision AuthoritySAML Authentication AuthoritySAML RequesterPost Binding (Liberty Alliance Optional)eGov (Liberty

Alliance Optional）AD FS 2.0

AD FS 2.0

AD FS 2.0

Slide101

SAML 2.0 プロファイル英語での名称日本語での名称Web Browser SSOWeb

ブラウザー SSOArtifact 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

属性

SAML 2.0

の

Use-Case

アサーション

/

プロトコル

/

バインディングの

組み合わせ

Slide102

Metadata属性のフォーマットクレームの暗号化署名Name ID(参考) Persistent ID と Transient IDCLR のチェック7.

AD FS 2.0 と SAML 2.0 対応製品 　相互運用のポイント

Slide103

相互運用のポイント～ MetadataAD FS 2.0 の場合Metadata には WS-Trust/WS-Federation に関する記述が存在する

パートナー側への読み込み時にエラーとなることがある対処法

WS-Trust/WS-Federation

に関する記載を

削除する

<

RoleDescriptor

xsi:type

="

fed:ApplicationServiceType

“

~

</

RoleDescriptor

>

<

RoleDescriptor

xsi:type="fed:SecurityTokenServiceType

”

~

</

RoleDescriptor

>

Slide104

相互運用のポイント～属性のフォーマット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

に変更

次のページ参照

Slide105

(参考) 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");

Slide106

相互運用のポイント～クレームの暗号化(Encryption)AD FS 2.0 の場合AES-256 を使用(例

) Java の場合 既定値は AES-128対処法

相手側も

AES-256

を使用する

or

AD FS 2.0

側で暗号化を無効にする

(

set-

ADFSRelyingPartyTrust

コマンドレット

)

Slide107

相互運用のポイント～署名 (Signing)AD FS 2.0 の場合規定で SHA-256 を使用するIdP の場合は アサーション、各種応答、

ログアウト要求SP の場合 は 認証依頼 (AuthnRequest) 、

ログアウト応答、アーティファクト

GET

対処法

AD FS 2.0

側で

SHA-1

を使用する

or

相手側も

SHA-256

を使用する

Slide108

相互運用のポイント ～ Name IDName 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

管理ツールで

クレーム変換

を定義する

Slide109

(参考) Persistent ID と Transient ID IDP の場合

RP の場合Persistent (持続

)

○

×

Transient

(

一時

)

○

○

厳密なプライバシーが要求されるシステムで使用

誰

がアクセス

している

のか

を 内部処理に隠ぺい

2

種類

の

Identity

形式

Persistent (

持続

)

：

Account Linking

Transient (

一時

)

：

Pseudo-anonymous

access

参考サイト

http://blogs.msdn.com/b/card/archive/2010/02/17/ name-identifiers-in-saml-assertions.aspx

Slide110

相互連携のポイント～ 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

Slide111

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

DI ソリューション事業部

Slide112

AD FS 2.0 と IDaaS の連携例112

Windows Azureオンプレミス

IdP

A

AD FS 2.0

IdP

B

AD FS 2.0

IDaaS

(3

rd

Party)

高度な認証

独自

ID

管理

SaaS A

（外部

ID

受入

)

SaaS B

(

独自

ID/PW

発行

)

信頼

同期

国内センタ

同期

信頼

WIF

WIF

信頼

Azure

利用企業の

ID

管理を代行

Azure

アプリの

ID

管理を代行

Azure

上のアプリ開発では、いままでよりも

ID

管理や認証が悩みどころに

WIF

ベースのアプリ開発で、オンプレミス

/

IDaaS

の

ID

管理・認証を活用

Slide113

ACS と IDaaS の連携例113

Windows AzureオンプレミスIdP

A

AD FS 2.0

ACS

V2

IDaaS

(3

rd

Party)

高度な認証

SaaS A

SaaS B

信頼

信頼

Yahoo

Facebook

Google

信頼

信頼

mixi

NTT

Twitter

外部クレーム情報の統合

and more...

国内センタ

複数の外部

IdP

と

高度認証との組合せ

ACS

を活用することで、非

WIF

ベースのアプリケーションでも様々な外部

IdP

を利用可能

ACS v2

がでるまでは

IDaaS

を信頼

Slide114

© 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