マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • IBM、Microsoft、Novellの各社によって開発されたクレームベース認証の仕様。
  • 主にエンプラ系で使用されるが、こちらはWS-Federationよりも、SAMLが主流になっている。
  • SAML Protocol ライク。
    • Assertionsには、SAML Assertionsを使用。
    • 以下のプロファイルがある。
      • パッシブリクエスタプロファイル(Webアプリ用)
      • アクティブリクエスタプロファイル(Webサービス用)

処理シーケンス

STS」や「IdP(CP)」が1つの場合

SAMLトークンのパッシブ モード

HTMLのWebアプリケーションがクライアントを認証する場合。

6. ↑ : 認証要求

7. ↓ : 認証完了

3. ↑ : STSであるADFSへのリダイレクト(No.2の続き)。

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

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

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

  • クライアント(WWWブラウザ)

1. ↓ : 匿名要求

2. ↑ : HTTP302によりSTSであるADFSへリダイレクト。

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

  • SP(RP)」であるWebアプリケーション

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

SAMLトークンのアクティブ モード

Web APIを呼び出すクライアントを認証する場合。

STS」や「IdP(CP)」が複数の場合

IdP(CP)側のSTS」と「SP(RP)」側のSTS」を数珠繋ぎにして、複数の「IdP(CP)」を選択可能にする構成。

SAMLトークンのパッシブ モード

HTMLのWebアプリケーションがクライアントを認証する場合。

SAMLトークンのアクティブ モード

Web APIを呼び出すクライアントを認証する場合。

SP(RP)STSの連携

参考

クレイジーな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だけをサポートしています。

Windows Azureエンタープライズアプリケーション開発技法

第2章 Windows Azureプラットフォーム概要 2.3.7 フェデレーション認証
http://www.atmarkit.co.jp/fdotnet/bookpreview/azureoverview_0203/azureoverview_0203_03.html

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

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

ID ソリューションで Active Directory フェデレーション サービス 2.0 を使用する

http://msdn.microsoft.com/ja-jp/magazine/ee335705.aspx

  1. アクティブ (WS-Trust) およびパッシブ (WS-Federation と SAML 2.0) をサポート。
  2. アーキテクチャ上、.NET -> WCF -> WIFの上位に構築されている。
  3. AD FS 2.0 はConfiguration Service, Card issuance Service, Security Token Service, Federation Metadata Serviceの集まりです。
    1. AD FS 2.0 の中核となるのがSTS(Security Token Service)です。STS は、ID ストアに Active Directory を、LDAPを、属性ストアに SQL ストアやカスタム ストアを使用します。
    2. 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)

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

セキュリティトークンの発行処理(クレームパイプライン)

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

2つに分かれている理由は、

  • CP:Claims Provider, クレームプロバイダ
  • RP:Relying Party, リライングパーティ

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

  • CP(Idp)
    • 受付変換規則:Acceptance Transform Rule
  • RP(SP)
    • 発行承認規則:Issuance Authorization rules
    • 発行変換規則:Issuance Transform Rule
  • 参考

Tags: :IT国際標準, :認証基盤, :クレームベース認証


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-09 (火) 22:17:14 (70d)