WS-Federation のバックアップ差分(No.14) - マイクロソフト系技術情報 Wiki

追加された行はこの色です。
削除された行はこの色です。
Open棟梁Project - マイクロソフト系技術情報 Wiki
[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]

-[[戻る>認証基盤]]

* 目次 [#sdd6d82f]
#contents

*概要 [#x2c4c7d0]
-SAML Protocol ライクな。
--以下のプロファイルがある。
---パッシブリクエスタプロファイル（Webアプリ用）
---アクティブリクエスタプロファイル（Webサービス用）

-Assertionsには、SAML Assertionsを使用。

*処理シーケンス [#sfe7b169]
**「[[STS>クレームベース認証#h4a44b62]]」や「[[IdP(CP)>クレームベース認証#h4a44b62]]」が１つの場合 [#rcec4cb1]
***SAMLトークンのパッシブ モード [#j4a8d6c6]

-「[[IdP(CP)>クレームベース認証#h4a44b62]]」である「[[ADDS>ドメイン サービス (AD DS)]]」~

>6. ↑ ： 認証要求

>7. ↓ ： 認証完了

-「[[STS>クレームベース認証#h4a44b62]]」である「[[ADFS>フェデレーション サービス (AD FS)]]

>3. ↑ ： [[STS>クレームベース認証#h4a44b62]]である[[ADFS>フェデレーション サービス (AD FS)]]へのリダイレクト（No.2の続き）。

>4. ↓ ： クライアントにログオン・ページを送信

>5. ↑ ： ユーザ・アカウント情報を入力して送信

>8. ↓ ： トークンを発行し、HTTP302によりWebアプリケーションへリダイレクト。

-クライアント（WWWブラウザ）

>1. ↓ ： 匿名要求

>2. ↑ ： HTTP302により[[ADFS>フェデレーション サービス (AD FS)]]へリダイレクト。

>9. ↓ ： トークンを使用してアクセス。

-「[[SP(RP)>クレームベース認証#h4a44b62]]」であるWebアプリケーション

>10.トークンを使用してアクセスを認可。

***SAMLトークンのアクティブ モード [#w73e5aeb]
・・・

**「[[STS>クレームベース認証#h4a44b62]]」や「[[IdP(CP)>クレームベース認証#h4a44b62]]」が複数の場合 [#r33d7b42]
「[[IdP(CP)>クレームベース認証#h4a44b62]]側の[[STS>クレームベース認証#h4a44b62]]」と「[[SP(RP)>クレームベース認証#h4a44b62]]」側の[[STS>クレームベース認証#h4a44b62]]」を数珠繋ぎにして、複数の「[[IdP(CP)>クレームベース認証#h4a44b62]]」を選択可能にする構成。

***SAMLトークンのパッシブ モード [#n2c3afd0]
・・・

***SAMLトークンのアクティブ モード [#s9167a14]
・・・

*参考 [#ef1d4176]

**クレイジーなWebサービス標準の全てを理解する [#z421ef49]
http://www.infoq.com/jp/articles/ws-standards-wcf-bustamante~

WS-Federation: 2006年12月 パブリックドラフト (PDF・英語)~
http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-fed/WS-Federation-V1-1B.pdf

-WS-Federationは、
--信頼されたドメイン間での識別子のフェデレーションサポートと、
--シングルサインオン・サインオフによるマッピングした識別子をサポートするために、
--WS-Security、WS-SecureConversation、WS-Trustにもとづいて構築された仕様です。

-WS-Federationには、2つのプロファイルがあります。

--パッシブリクエスタプロファイル:~
---このプロファイルは、現在、PingFederateやADFSといった製品によってサポートされています。
---ブラウザーをベースとしたシングルサインオン(SSO)やアイデンティティフェデレーション(ID連携)を可能にします。

--アクティブリクエスタプロファイル:~
---このプロファイルは、現在、PingTrustによってサポートされており、将来的にはADFSでサポートされる予定です。
---Webサービス上のアイデンティティフェデレーションをサポートします。

-WS-Federationは、SAML(Security Assertion Markup Language)2.0と類似した問題を解決しますが、他のWS*プロトコルで構成可能です。

--それは例えば、信頼メッセージングやトランザクションに関連するものです。

--従って、あなたがエンタープライズレベルのフェデレーションをソリューションとして組み込みたいのなら、~
ドメイン内の参加者によってどのプロトコルが実装されているのかについて注意を払わなければならないでしょう。

--PingFederateやPingTrustのような製品は、SAML 2.0やWS-Federationの両方をサポートしています。

--また、Liberty Allianceは、SAML 2.0を、ADFSやWindows Live IDは、WS-Federationだけをサポートしています。

-WS-Federationのパブリックドラフトは、最近、OASIS WSFED 技術委員会へのインプットとして受け入れられました
--http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed (英語)
--この委員会の下で、SAML 2.0とWS-Federationが標準化されることを期待します。

**Windows Azureエンタープライズアプリケーション開発技法 [#z72cd9f9]
第2章　Windows Azureプラットフォーム概要　2.3.7　フェデレーション認証~
http://www.atmarkit.co.jp/fdotnet/bookpreview/azureoverview_0203/azureoverview_0203_03.html

大まかな動作は以下の通りである。

+セキュリティトークン（通常はクッキー情報により取り扱われる）を持たない状態で、社外（ここではAzure環境）のアプリケーションにアクセスを試みると、アクセスが拒否される。
+そしてそれと共に、社内のフェデレーションサーバーにセキュリティトークンを取りに行くように指示される（社内のフェデレーションサーバーへのリダイレクトが行われる）。
+エンドユーザーがフェデレーションサーバーにアクセスすると、ユーザー確認が行われ、セキュリティトークンが発行される。
+このセキュリティトークンを持った形で社外のアプリケーションにアクセスすると、このセキュリティトークンの真贋判定が行われる。正しいものだった場合、アプリケーションにアクセスできるようになる。

**ID ソリューションで Active Directory フェデレーション サービス 2.0 を使用する [#a3276d68]
http://msdn.microsoft.com/ja-jp/magazine/ee335705.aspx
+アクティブ (WS-Trust) およびパッシブ (WS-Federation と SAML 2.0) をサポート。
+アーキテクチャ上、.NET -> WCF -> WIFの上位に構築されている。
+AD FS 2.0 はConfiguration Service, Card issuance Service, Security Token Service, Federation Metadata Serviceの集まりです。
++AD FS 2.0 の中核となるのがSTS(Security Token Service)です。STS は、ID ストアに Active Directory を、LDAPを、属性ストアに SQL ストアやカスタム ストアを使用します。
++AD FS 2.0 の STS は、WS-Trust、WS-Federation、SAML (Security Assertion Markup Language) 2.0 などのさまざまなプロトコルを使用して、呼び出し元にセキュリティ トークンを発行します。トークン形式としては、SAML 1.1 と SAML 2.0 の両方をサポートします。

**AD FS 2.0 Deep Dive ～ 要求規則を極める ～ [#uf2a5ae6]
http://www.slideshare.net/junichia/ad-fs-deep-dive-claim-rule-set

***用語 [#od599955]
http://www.slideshare.net/junichia/ad-fs-deep-dive-claim-rule-set/12
|英語|日本語|h
|要求|Claim, クレーム|
|規則|Rule, ルール|
|要求の種類|Claim Type, クレームタイプ|
|要求記述|Claim Description, クレームディスクリプション|
|要求プロバイダー|Claim Provider, クレームプロバイダー|
|証明書利用者|Relying Party, リライングパーティ|
|受付変換規則|Acceptance Transform Rule|
|発行承認規則|Issuance Authorization rules|
|発行変換規則|Issuance Transform Rule|

***要求規則（Claim Rule） [#dc4e6441]
http://www.slideshare.net/junichia/ad-fs-deep-dive-claim-rule-set/13

入力：[[Idp(CP)>クレームベース認証#h4a44b62]]

↓

-受け付け変換規則 : 受信クレームの受け入れ
-発行承認規則 : クレーム要求者の承認
-発行変換規則 : 送信クレームの発行
--パススルー
--変換
--フィルター

↓

出力：[[SP(RP)>クレームベース認証#h4a44b62]]

-参考
--要求規則~
https://technet.microsoft.com/ja-jp/library/dd727964.aspx
---要求規則を使用した要求の発行
---要求規則を使用した承認
---要求としての LDAP 属性の送信
---要求としてのグループ メンバーシップの送信
---入力方向の要求の変換
---入力方向の要求のパス スルーまたはフィルター処理
---入力方向の要求に基づくユーザー アクセスの許可または拒否
---すべてのユーザーの許可
---カスタム規則を使用した要求の送信
---要求規則言語

***セキュリティトークンの発行処理（クレームパイプライン） [#c299051a]
http://www.slideshare.net/junichia/ad-fs-deep-dive-claim-rule-set/14~
－http://www.slideshare.net/junichia/ad-fs-deep-dive-claim-rule-set/17

２つに分かれている理由は、
-[[CP>クレームベース認証#h4a44b62]]:Claims Provider, クレームプロバイダ
-[[RP>クレームベース認証#h4a44b62]]:Relying Party, リライングパーティ

が別の組織である場合に対応するため。

-[[CP(Idp)>クレームベース認証#h4a44b62]]側
--受付変換規則：Acceptance Transform Rule

-[[RP(SP)>クレームベース認証#h4a44b62]]側
--発行承認規則：Issuance Authorization rules
--発行変換規則：Issuance Transform Rule

-参考
--要求規則のウィザードと編集用ダイアログ ボックス~
https://technet.microsoft.com/ja-jp/library/gg557797.aspx
---[[CP>クレームベース認証#h4a44b62]] 規則の編集: [受付変換規則] タブ
---[[RP>クレームベース認証#h4a44b62]] 規則の編集: [発行変換規則] タブ
---[[RP>クレームベース認証#h4a44b62]] 規則の編集: [発行承認規則] タブ
---[[RP>クレームベース認証#h4a44b62]] 規則の編集: [委任承認規則] タブ