Skip to content

MS_WSFederation

Jump to bottom
nishi_74322014 edited this page Aug 4, 2026 · 1 revision

WS-Federation

概要

  • IBM、Microsoft、Novell の各社によって開発された クレームベース認証 の仕様。

  • 主にエンプラ系で使用されるが、こちらは WS-Federation よりも、
    SAML が主流になっている。

  • SAML Protocol ライク。

    • Assertions には、SAML Assertions を使用。
    • 以下のプロファイルがある。
      • パッシブリクエスタプロファイル（Web アプリ用）
      • アクティブリクエスタプロファイル（Web サービス用）

補足: WS-Federation は WS-* 仕様群の一員であり、 WS-Security / WS-Trust / WS-SecureConversation の上に構築されている。 SOAP で触れたとおり、 WS-* は組み合わせの複雑さゆえに敬遠され、 WS-Federation もその影響を受けた。

なお「パッシブ」「アクティブ」の呼び分けは、 クライアントがプロトコルを理解しているかによる。

プロファイル クライアント 仕組み
パッシブ WWW ブラウザ（プロトコルを知らない） HTTP リダイレクトと POST で誘導する
アクティブ アプリ（プロトコルを知っている） WS-Trust で STS に直接トークンを要求する

処理シーケンス

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

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

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

# 主体 向き 内容
1 クライアント（WWW ブラウザ） → 匿名要求
2 クライアント ← HTTP 302 により STS である ADFS へリダイレクト
3 ADFS ← STS である ADFS へのリダイレクト（No.2 の続き）
4 ADFS → クライアントにログオン・ページを送信
5 ADFS ← ユーザ・アカウント情報を入力して送信
6 ADDS ← 認証要求
7 ADDS → 認証完了
8 ADFS → トークンを発行し、HTTP 302 により Web アプリケーションへリダイレクト
9 クライアント → トークンを使用してアクセス
10 SP(RP) である Web アプリケーション トークンを使用してアクセスを認可

補足: 手順 8 の「HTTP 302 によるリダイレクト」は、 実際には HTTP 302 ではなく自動 POST（wresult を含むフォーム） で RP に渡されるのが一般的である。 SAML トークンは URL の長さ制限に収まらないことが多いためで、 SAML 2.0 で言う HTTP POST Binding に相当する。

この「ブラウザが自動 POST するフォーム」が、 SameSite属性の件 で問題になる典型例である。 SameSite=Lax ではクロスサイトの POST にクッキーが送られないため、 RP 側のセッション クッキーに SameSite=None; Secure が必要になるケースがある。

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

Web API を呼び出すクライアントを認証する場合。
クライアントが WS-Trust で STS からトークンを取得し、
それを SOAP ヘッダに載せて Web サービスを呼び出す。

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

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

  • SAML トークンのパッシブ モード — HTML の Web アプリケーションが
    クライアントを認証する場合。
  • SAML トークンのアクティブ モード — Web API を呼び出す
    クライアントを認証する場合。

補足: この構成では、 ユーザにどの IdP を使うか選ばせる画面（Home Realm Discovery）が必要になる。 ADFS では、 RP ごとに既定の IdP を固定したり、 メール アドレスのドメインから自動判別したりできる。

SP(RP)とSTSの連携

  • WIFを使用する。

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

    1. アクティブ (WS-Trust) およびパッシブ (WS-Federation と SAML 2.0) をサポート。
    2. アーキテクチャ上、.NET → WCF（MS_WCF.md）→ WIF の上位に構築されている。
    3. AD FS 2.0 は Configuration Service, Card issuance Service,
      Security Token Service, Federation Metadata Service の集まりである。
      • AD FS 2.0 の中核となるのが STS である。
        STS は、ID ストアに Active Directory を、LDAP を、
        属性ストアに SQL ストアやカスタム ストアを使用する。
      • AD FS 2.0 の STS は、WS-Trust、WS-Federation、SAML 2.0 などの
        さまざまなプロトコルを使用して、呼び出し元にセキュリティ トークンを発行する。
        トークン形式としては、SAML 1.1 と SAML 2.0 の両方をサポートする。

要求規則（Claim Rule）

用語

英語 日本語
Claim 要求、クレーム
Rule 規則、ルール
Claim Type 要求の種類、クレームタイプ
Claim Description 要求記述、クレームディスクリプション
Claim Provider 要求プロバイダー、クレームプロバイダー
Relying Party 証明書利用者、リライングパーティ
Acceptance Transform Rule 受付変換規則
Issuance Authorization Rule 発行承認規則
Issuance Transform Rule 発行変換規則

処理の流れ

入力：IdP(CP)

↓

  • 受付変換規則（Acceptance Transform Rule）: 受信クレームの受け入れ
  • 発行承認規則（Issuance Authorization Rule）: クレーム要求者の承認
  • 発行変換規則（Issuance Transform Rule）: 送信クレームの発行
    • パススルー
    • 変換
    • フィルター

↓

出力：SP(RP)

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

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

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

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

側 規則
CP(IdP) 側 受付変換規則（Acceptance Transform Rule）
RP(SP) 側 発行承認規則（Issuance Authorization Rule）、発行変換規則（Issuance Transform Rule）

補足: フェデレーション サービス (AD FS) の該当箇所と同じ内容だが、 発行承認規則 = Issuance Authorization Rule（アクセスの可否）、 発行変換規則 = Issuance Transform Rule（クレームの整形） という対応を取り違えやすい。 「承認＝通すか否か」「変換＝何を渡すか」と覚えるとよい。

現在の位置付け

補足（最新化）: 元ページの 「WS-Federation よりも SAML が主流」という評価は、 さらに進んで OpenID Connect が主流という状況になっている。

  • WS-Federation — ADFS や SharePoint との連携で残存
  • SAML 2.0 — SaaS への SSO で現役
  • OpenID Connect — 新規開発の第一候補

ASP.NET Core では Microsoft.AspNetCore.Authentication.WsFederation パッケージで WS-Federation の RP を実装できるが、 新規に選ぶ理由は乏しい。

参考

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally