Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
- SAML Protocol ライクな。
- 以下のプロファイルがある。
- パッシブリクエスタプロファイル（Webアプリ用）
- アクティブリクエスタプロファイル（Webサービス用）
- Assertionsには、SAML Assertionsを使用。
処理シーケンス †
SAMLトークンのパッシブ モード †
6. ↑ ： 認証要求
7. ↓ ： 認証完了
3. ↑ ： STSであるADFSへのリダイレクト（No.2の続き）。
4. ↓ ： クライアントにログオン・ページを送信
5. ↑ ： ユーザ・アカウント情報を入力して送信
8. ↓ ： トークンを発行し、HTTP302によりWebアプリケーションへリダイレクト。
1. ↓ ： 匿名要求
2. ↑ ： HTTP302によりADFSへリダイレクト。
9. ↓ ： トークンを使用してアクセス。
10.トークンを使用してアクセスを認可。
SAMLトークンのアクティブ モード †
・・・
「IdP(CP)側のSTS」と「SP(RP)」側のSTS」を数珠繋ぎにして、複数の「IdP(CP)」を選択可能にする構成。
SAMLトークンのパッシブ モード †
・・・
SAMLトークンのアクティブ モード †
・・・
参考 †
クレイジーなWebサービス標準の全てを理解する †
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 技術委員会へのインプットとして受け入れられました
Windows Azureエンタープライズアプリケーション開発技法 †
第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 を使用する †
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 ～ 要求規則を極める ～ †
http://www.slideshare.net/junichia/ad-fs-deep-dive-claim-rule-set
用語 †
http://www.slideshare.net/junichia/ad-fs-deep-dive-claim-rule-set/12
| 英語 | 日本語 |
| 要求 | Claim, クレーム |
| 規則 | Rule, ルール |
| 要求の種類 | Claim Type, クレームタイプ |
| 要求記述 | Claim Description, クレームディスクリプション |
| 要求プロバイダー | Claim Provider, クレームプロバイダー |
| 証明書利用者 | Relying Party, リライングパーティ |
| 受付変換規則 | Acceptance Transform Rule |
| 発行承認規則 | Issuance Authorization rules |
| 発行変換規則 | Issuance Transform Rule |
要求規則（Claim Rule） †
http://www.slideshare.net/junichia/ad-fs-deep-dive-claim-rule-set/13
入力：Idp(CP)
↓
↓
出力：SP(RP)
セキュリティトークンの発行処理（クレームパイプライン） †
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:Claims Provider, クレームプロバイダ
- RP:Relying Party, リライングパーティ
が別の組織である場合に対応するため。
- CP(Idp)側
- 受付変換規則：Acceptance Transform Rule
- RP(SP)側
- 発行承認規則：Issuance Authorization rules
- 発行変換規則：Issuance Transform Rule
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
