Skip to content

MS_SAMLSpecReading

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

SAMLの仕様を読む。

概要

汎用認証サイトに SAML2.0を実装するため仕様を読む。

  • ターゲットは SP Initiated な Web Browser SSO Profile に絞る。
  • ココに書いた情報は、SAML の Technical Overview と他社コンテンツの情報の範囲。

補足（読む順序）: SAML 2.0 の仕様書は 8 本あり、総ページ数も多い。
全部を通読する必要はなく、次の順で読むのが実際的である。

  1. Technical Overview（非規範。全体像とシーケンス図）
  2. Profiles（実現したいユースケースを 1 つ選ぶ）
  3. Bindings（そのプロファイルが使う伝送方式だけ）
  4. Core（そこで登場する要素の定義だけを引く）

Core を頭から読むと挫折する。Profile → Binding → Core と
上から降りていくのが正解である。

ロードマップ

仕様書 内容
Technical Overview SAML 2.0 の技術概要（非規範）
Profiles 特定のユースケースを実現するための組み合わせ方を定義
Bindings メッセージを実際の通信プロトコル（HTTP など）にマッピングする方法を定義
Core（Assertions and Protocols） 認証・属性・許可情報を記述した XML の構文とセマンティクス
SAML Metadata SAML パーティ間で設定情報を表現・共有する XML スキーマ
Authentication Context 認証メカニズムを記述する宣言の構文
XML Signature Syntax and Processing XML デジタル署名処理規則と構文（XML署名・暗号）

  • Profiles

    • セキュリティ情報を伝達するための SAML の豊富で柔軟な
      構文を使用および制限するための一連の特定の規則を定義。
    • 属性プロファイルの構文の側面をカバーするいくつかの関連する小さなスキーマ。

  • Core

    • アサーション用とプロトコル用のスキーマを定義する。

  • SAML Metadata

    • SP が IdP を利用するための情報を記述して、IdP と SP の信頼関係を構築できる。
      • エンティティのサポートされている SAML バインディング
      • 運用上の役割（IdP、SP など）
      • 識別子情報、サポート ID 属性
      • および暗号化と署名のための鍵情報

  • Authentication Context

    • 認証のタイプと強度に関する詳細な情報を SP が要求し、IdP は、これに応答する。

ユースケース

参加者

  • システム・エンティティ
    システム・エンティティは、さまざまな SAML ロールで動作するが、
    最低限、SAML 交換は、以下のシステム・エンティティ間で行われる。

    • アサーティング・パーティ（SAML オーソリティ）

      • SAML アサーションを行うシステム・エンティティ
      • ユーザもアサーティング・パーティの参加者である可能性がある。

    • リライング・パーティ（RP）
      受け取ったアサーションを使用するシステム・エンティティ

  • リクエスタ / レスポンダ

    • アサーティング・パーティとリライング・パーティは、
      SAML リクエスタにもレスポンダにもなりうる。
    • アサーティング・パーティの情報に依存するという回答側の意向は、
      アサーティング・パーティとの信頼関係に依存

  • ロール

    • SSO のロール

      • Identity プロバイダ（IdP）≒ アサーティング・パーティ（SAML オーソリティ）
      • Service プロバイダ（SP）≒ リライング・パーティ

    • ID 連携のロール

      • 属性リクエスタ — アイデンティティ属性クエリ
      • 属性機関の役割 — アイデンティティ属性クエリに応答して SAML エンティティがアサーションを生成

  • サブジェクト ≒ プリンシパル

    • 殆どの SAML アサーションの中心にある対象
    • 通常は人間、それ以外にも会社やコンピュータなどエンティティを表す。

  • あとは、だいたい、OpenID Connectと同じ。

補足（OIDC との用語対応）: 実際、対応関係を押さえておくと理解が早い。

SAML OpenID Connect
IdP（Identity Provider） OP（OpenID Provider）
SP（Service Provider） RP（Relying Party）
アサーション（Assertion） ID トークン
<AuthnRequest> 認可リクエスト
<Response>（POST） 認可レスポンス（form_post）
Artifact 認可コード
RelayState state
<Audience> aud クレーム
NameID sub クレーム
メタデータ openid-configuration / jwks_uri
Circle of Trust クライアント登録

「XML + 署名」か「JSON + JWS」かの違いが大きく、
設計思想はよく似ている。

Web-SSO

  • マルチドメイン Web シングルサインオン
  • SAML が適用される最も重要なユースケース
  • これも、あとは、だいたい、OpenID Connectと同じ。

IDフェデレーション

  • 考慮しなければならない多くの質問

    • ユーザーは、既存のローカル ID をサイトに持っているか？
    • ユーザーの連合 ID の確立と終了は静的か？動的か？
    • ユーザーは連合 ID の確立に明示的に同意する必要があるか？
    • ユーザーに関する ID 属性を交換する必要があるか？
    • ID フェデレーションは、SessionID などの識別子に依存するべきか？
    • 情報が暗号化されるべきか？交換される情報のプライバシーは大きな関心事か？

  • 連合 ID 機能を強化するための 2 つの機能

    • フェデレーション名識別子の動的確立と管理をサポートする、新しい構成とメッセージ
    • プライバシー保護の特徴を持った 2 つの新しいタイプの名前識別子

  • プロバイダー間のユーザー情報の維持および更新

    • 追加のフローは必要のないケース。
    • 追加のフローが必要になるケース。
      SAML V2.0 メッセージ交換の外部で行われるケース
      • IdP におけるデータソースによって駆動され、
      • SP に伝播されるバッチまたはオフラインの ID フィードを利用

アカウントリンク

連合 ID をローカル ID と関連付けるプロセスは、アカウントリンクと呼ばれる。

  • IdP 検出機能を使用し、SP から IdP にアカウントリンクするかしないかをユーザに問う。
  • ユーザが、フェデレーションに同意すると IdP にリダイレクトされる。
  • IdP で SP のフェデレーション名識別子が生成され、IdP 上のアカウントにリンクされる。
  • IdP で SP は、後続のトランザクションでこの識別子を使用してユーザを参照する。
  • IdP から SP にリダイレクトされた後、この識別子を SP のローカル・アカウントに関連付ける。

※ 追加のサイトとアカウントリンクする場合は、
　新たにフェデレーション名識別子を生成し、上記手順を繰り返す。

アーキテクチャ

基本概念

基本的なSAMLの概念

（Profile（Binding（Protocol（Assertion））））

                     ・Metadata
                     ・Authentication Context

  • Assertions
    アサーティング・パーティが真実であると主張するプリンシパルに関する
    ステートメントを伝える XML スキーマによって定義されたアサーション。

    • リライング・パーティからの要求に基づいてアサーティング・パーティによって作成される。
    • 特定の状況下では、アサーションは未承諾の方法でリライング・パーティに配信できる。

  • Protocols

    • SAML のリクエスト / レスポンスを行うプロトコル。
    • これにより、アサーションの入手や、ID マネジメントを行う。

  • Bindings
    参加者間で SAML プロトコル・メッセージを転送するために下位レベルの
    通信またはメッセージングプロトコル（HTTPまたはSOAPなど）を使用する方法

  • Profiles

    • Web ブラウザ SSO プロファイルなどの特定のユースケースを満たすように定義される。
    • SAML アサーション、プロトコル、およびバインディングの内容に対する制約を定義する。
    • プロトコルメッセージやバインディングを参照しない属性プロファイルもある。
      （X.500 / LDAP、DCE などの一般的な使用環境と一致する方法でアサーションを使用）

構築と展開の2つの概念

# Authentication Context 説明
1 urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified 不特定の方法で認証したことを示す。
2 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport HTTPS でパスワードを提示して認証したことを示す（≒ 既定値）
3 urn:oasis:names:tc:SAML:2.0:ac:classes:Password HTTP でパスワードを提示して認証したことを示す（推奨されない）
4 urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession セッション等を使用し、すでに認証済みであること／過去のある時点で認証したことを示す。
5 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 デジタル署名により認証したことを示す。

移行メモ（正誤）: 元ページは 2 行目と 3 行目の URI が
どちらも PasswordProtectedTransport になっていた。
説明文（HTTPS / HTTP）から見て 3 行目は Password が正しいため、そのように改めた。

高度な概念

  • Subject Confirmation

    • Assertions には、<SubjectConfirmation> という要素を含めることができる。

    • 実際的には、Subject Confirmation は、

      • Assertion の利用者が許可されている条件
      • ≒ SP が検証を行うための手段を提供する。

    • Method 属性に 3 つの値を定義することによって、
      3 つの異なるセキュリティシナリオに対応する。

Method 内容
urn:oasis:names:tc:SAML:2.0:cm:bearer 所謂、一つの、持参人切符
urn:oasis:names:tc:SAML:2.0:cm:holder-of-key <SubjectConfirmationData> を使用した、記名式切符
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches どの RP がその Claim を使用することを許可されるべきかを決定する際に他の基準を使用

SAML Components

Assertions

通常、アサーションは以下から構成される。

  • アサーションの subject

    • subject（主題）
    • subject が存在しない場合、他の方法で識別される。
      例えば subject の確認に使用された証明書

  • アサーションの検証条件

  • アサーション・ステートメント

ステートメント 内容
Authentication statements ユーザーを正常に認証した当事者によって作成される。最低でも、認証に使用される特定の手段と認証が行われた特定の時間を説明。
Attribute statements サブジェクトに関する特定の識別属性。例えば、ユーザー "John Doe" は "ゴールドカードステータス" を持つ。
Authorization decision statements 対象がする権利があるものを定義する。例えば、ユーザー "John Doe" は "特定の品目を購入すること" が許可されている。

補足: <AuthzDecisionStatement> は SAML 2.0 で
**非推奨（deprecated）**とされている。
認可判断は XACML に
委ねる設計が推奨されており、実装もほぼ存在しない。
実務で使うのは Authentication / Attribute の 2 つである。

Protocols

いくつかの一般化された要求 / 応答プロトコルを定義する。

プロトコル 内容
Authentication Request Protocol Authentication / Attribute statements を含むアサーションを要求できるようにする手段を定義。Web Browser SSO Profile で、SP から IdP にユーザをリダイレクトするときに使用する。
Single Logout Protocol プリンシパルのアクティブ・セッションのログアウト・メカニズムを定義。ユーザ（直接開始）、SP / IdP（Session タイムアウト、管理者コマンド）から開始できる。
Assertion Query and Request Protocol アサーションを取得するための一連のクエリを定義
Artifact Resolution Protocol アーティファクトと呼ばれる小さな固定長の値を使用して、メッセージを参照によって渡すことができるメカニズムを提供
Name Identifier Management Protocol プリンシパルを参照するために使用される名前識別子の形式変換・関連付けの開始 / 終了のメカニズムを提供。要求の発行者は、SP / IdP のどちらでもかまわない。
Name Identifier Mapping Protocol 適切なポリシー制御に従って、名前識別子を別の名前識別子にマッピングするためのメカニズムを提供。アプリケーション統合シナリオでは、ある SP が IdP から別の SP で使用できるユーザーの名前識別子を要求することを許可する。

Bindings

トランスポート層上で、プロトコルメッセージをどのように伝達するか？

Binding 内容
HTTP Redirect Binding リダイレクト（302 応答）を使用してプロトコルメッセージを転送する方法を定義
HTTP POST Binding HTML の form コントロール（base64）でプロトコルメッセージを転送する方法を定義
HTTP Artifact Binding Artifact Resolution Protocol を使用して、プロトコルメッセージを転送する方法を定義。HTML の form コントロールと、URL 中の Query string を使用する方法がある。
SAML SOAP Binding SOAP 1.1 を使用して、プロトコルメッセージが転送される方法を定義
Reverse SOAP (PAOS) Binding HTTP クライアントを SOAP レスポンダにする多段階の SOAP / HTTP メッセージ交換を定義。IdP ディスカバリをサポートする拡張クライアントおよびゲートウェイ・プロキシで使用
SAML URI Binding URI を解決することによって既存の SAML アサーションを取得するための手段を定義

Profiles

特定シナリオでアサーション、プロトコル、バインディングの組合せ（制約）を定義

Profile 使用するプロトコル 使用できる Binding
Web Browser SSO Profile Authentication Request Protocol HTTP Redirect / HTTP POST / HTTP Artifact
Enhanced Client and Proxy (ECP) Profile Authentication Request Protocol Reverse-SOAP (PAOS) / SOAP
Identity Provider Discovery Profile （なし。Common Domain Cookie） —
Single Logout Profile Single Logout Protocol HTTP Redirect / HTTP POST / HTTP Artifact / SAML SOAP
Assertion Query and Request Profile Assertion Query and Request Protocol 同期バインディング
Artifact Resolution Profile Artifact Resolution Protocol SAML SOAP
Name Identifier Management Profile Name Identifier Management Protocol HTTP Redirect / HTTP POST / HTTP Artifact / SAML SOAP
Name Identifier Mapping Profile Name Identifier Mapping Protocol SAML SOAP

EndPoint

この項目は、SAML の公式資料にはないが、図を見ると、
EndPoint には以下の様な名称が付与されている。

用途 EndPoint
Single sign-on / SAML Request を受ける SSO Service（<md:SingleSignOnService>）
Single sign-on / SAML Response を受ける Assertion Consumer Service（<md:AssertionConsumerService>）
Artifact Request を受ける Artifact Resolution Service
Single logout / Logout Request・Response を受ける Single Logout Service
Termination / ManageNameIDRequest を受ける Manage NameID Service
  • Artifact Request を発行する EndPoint
    • SSO Service（Request で Artifact を使用する場合）
    • Assertion Consumer Service（Response で Artifact を使用する場合）

SAML XML構造と例

SAMLコンポーネントとの関係

Transport Protocol
├─ Transport Protocol ヘッダ
└─ Transport Protocol ペイロード
   └─ レスポンス（アサーション）
      ├─ Authentication statements
      └─ Other statements

Assertion、Subject、Statementの構造

  • 単一の Authentication statement を含む Assertion の例を含む XML フラグメント
<saml:Assertion
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  Version="2.0" IssueInstant="2005-01-31T12:00:00Z">
  <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
    http://idp.example.org
  </saml:Issuer>
  <saml:Subject>
    <saml:NameID
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      j.doe@example.com
    </saml:NameID>
  </saml:Subject>
  <saml:Conditions
    NotBefore="2005-01-31T12:00:00Z"
    NotOnOrAfter="2005-01-31T12:10:00Z">
  </saml:Conditions>
  <saml:AuthnStatement
    AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
</saml:Assertion>

移行メモ: 元の掲載では <saml:Issuer> の Format 属性値が
引用符無しで urn:oasis:names:SAML:2.0:nameid-format:entity>> と
崩れていたため、スキーマ上正しい
urn:oasis:names:tc:SAML:2.0:nameid-format:entity に整えた。

Attribute statementsの構造

  • SAML の属性構造は、特定のタイプの

    • データストア
    • データタイプ

    が属性に使用されているとは想定していない。

  • 注意

    • 単一のステートメントに複数の属性を含めることができる。
    • 属性名は、属性名を解釈する名前形式で修飾される。
<saml:AttributeStatement>
  <saml:Attribute
    xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
    Name="urn:oid:2.5.4.42" FriendlyName="givenName">
    <saml:AttributeValue xsi:type="xs:string" x500:Encoding="LDAP">
      John
    </saml:AttributeValue>
  </saml:Attribute>
  <saml:Attribute
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
    Name="LastName">
    <saml:AttributeValue xsi:type="xs:string">
      Doe
    </saml:AttributeValue>
  </saml:Attribute>
  <saml:Attribute
    xmlns:smithco="http://www.smithco.com/smithco-schema.xsd"
    NameFormat="http://smithco.com/attr-formats"
    Name="CreditLimit">
    <saml:AttributeValue xsi:type="smithco:type">
      <smithco:amount currency="USD">500.00</smithco:amount>
    </saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>

Message構造とSOAP Binding

  • SAML パーティが SOAP 対応である環境では、
    SOAP Binding を使用して SAML 要求 / 応答プロトコルメッセージを交換できる。
HTTP Response
└─ SOAP envelope
   ├─ SOAP ヘッダ
   └─ SOAP ボディ … SAML リクエスト or SAML レスポンス
  • 例（Attribute Query in SOAP Envelope）
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
  xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Body>
    <samlp:AttributeQuery
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
      ID="aaf23196-1773-2113-474a-fe114412ab72"
      Version="2.0" IssueInstant="2006-07-17T20:31:40Z">
      <saml:Issuer>
        http://example.sp.com
      </saml:Issuer>
      <saml:Subject>
        <saml:NameID
          Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
          C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu
        </saml:NameID>
      </saml:Subject>
      <saml:Attribute
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        Name="urn:oid:2.5.4.42" FriendlyName="givenName">
      </saml:Attribute>
    </samlp:AttributeQuery>
  </env:Body>
</env:Envelope>
  • 例（Response in SOAP Envelope）
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Body>
    <samlp:Response
      xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="i92f8b5230dc04d73e93095719d191915fdc67d5e"
      Version="2.0" IssueInstant="2006-07-17T20:31:41Z"
      InResponseTo="aaf23196-1773-2113-474a-fe114412ab72">
      <saml:Issuer>
        http://idp.example.org
      </saml:Issuer>
      <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
      </samlp:Status>
      <!-- SAML assertion -->
    </samlp:Response>
  </env:Body>
</env:Envelope>

プライバシー

情報技術の文脈では、プライバシは一般に、

  • 自分の ID データがどのように共有され使用されるかを制御するユーザの能力
  • 複数の SP での彼らの行動が不適切に関連付けられるのを妨げるメカニズム

の両方を指す。

ユーザの能力

  • ID データの共有を制御するユーザの能力が必要になる。
  • この同意がどのように行われるかは、SAML の範囲外。
  • SAML は、ID データの共有を制御するため、以下をサポートする。
    • Authentication Contextにより
      十分な保証レベルでユーザを認証できる。
    • 特定の操作に同意したユーザのクレームをプロバイダ間で表現する。

メカニズム

仮名の確立をサポート（PPIDを参照）。

セキュリティ

  • 公開鍵基盤（PKI）に依存する信頼関係を推奨
  • HTTP over SSL 3.0 または TLS 1.0 を推奨

補足（最新化）: SSL 3.0 は POODLE 攻撃により RFC 7568 で禁止、
TLS 1.0 / 1.1 も RFC 8996 で非推奨となっている。
現在は **TLS 1.2 以上（可能なら 1.3）**が要件である
（SSL/TLSを参照）。

同様に、SAML 2.0 の既定署名アルゴリズムは rsa-sha1 だが、
SHA-1 は使ってはならない。rsa-sha256（以上）を使い、
受信側でも SHA-1 署名を拒否する設定にする。

主要ProfileとFederationのUseCase

Web Browser SSO Profile

使用される可能性が高い典型的なフローで、主に 2 つのオプションがある。

  • 1 つ目はフローが SP 開始または IdP 開始のどちらであるか

    • SP 開始：SP で開始される Web SSO モデル

      • ユーザは SP にログインしていないため、リソースへのアクセスを許可する前に、
        SP はユーザを IdP に送信する。
      • IdP でユーザを認証し、IdP は、アサーションを作成し、アサーションを SP に送り返す。
      • SP は、アサーションを検証し、ユーザにリソースへのアクセスを許可するかどうかを決定。

    • IdP 開始：IdP で開始される Web SSO モデル

      • ユーザは既に認証されていて、IdP 上の SP へのリンクをクリック。
      • IdP はアサーションを作成し、アサーションを SP に送信。
      • SP は、アサーションを検証し、ユーザにリソースへのアクセスを許可するかどうかを決定。

  • 2 つ目は IdP と SP 間のメッセージ配信に使用されるバインディング

    • Authentication Request message — HTTP Redirect / HTTP POST / HTTP Artifact
    • Authentication Response message — HTTP POST / HTTP Artifact

補足（IdP 開始は避ける）: IdP 開始 SSO は、
<Response> に InResponseTo が無い（対応する要求が存在しない）ため、
未承諾のアサーションを受理することになる。

これは実質的に **CSRF（ログイン CSRF）**の入口であり、
攻撃者が入手したアサーションを被害者のブラウザに POST させると、
攻撃者のアカウントでログインさせられる（その後の操作が攻撃者に見える）。

OpenID Connect が
IdP 開始フローを明確に非推奨としているのと同じ理由である。
業務要件で必要な場合も、SP 開始にリダイレクトして仕切り直す
（IdP 開始のリンクは「SP のログイン開始 URL を叩くだけ」にする）
という実装が推奨される。

SP-Initiated SSO: Redirect/POST Bindings

  • Authentication Request message — HTTP Redirect Binding でリクエスト
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=value

HTTP/1.1 302 Found
Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=value

GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=value HTTP/1.1
Host: idp.example.org

<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_1" Version="2.0"
  IssueInstant="2004-12-05T09:21:59Z"
  AssertionConsumerServiceIndex="1">
  <saml:Issuer>
    https://sp.example.com/SAML2
  </saml:Issuer>
  <samlp:NameIDPolicy
    AllowCreate="true"
    Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
  • Authentication Response message — HTTP POST Binding でレスポンス
<form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
  <input type="hidden" name="SAMLResponse" value="response" />
  <input type="hidden" name="RelayState" value="value" />
  <input type="submit" value="Submit" />
</form>
POST /SAML2/SSO/POST HTTP/1.1
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn

SAMLResponse=response&RelayState=value

<samlp:Response
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_2" InResponseTo="identifier_1"
  Version="2.0" IssueInstant="2004-12-05T09:22:05Z"
  Destination="https://sp.example.com/SAML2/SSO/POST">
  <saml:Issuer>
    https://idp.example.org/SAML2
  </saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode
      Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_3" Version="2.0"
    IssueInstant="2004-12-05T09:22:05Z">
    <saml:Issuer>
      https://idp.example.org/SAML2
    </saml:Issuer>
    <!-- a POSTed assertion MUST be signed -->
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      ...
    </ds:Signature>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
        3f7b3dcf-1674-4ecd-92c8-1544f346baf8
      </saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData
          InResponseTo="identifier_1"
          Recipient="https://sp.example.com/SAML2/SSO/POST"
          NotOnOrAfter="2004-12-05T09:27:05Z"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions
      NotBefore="2004-12-05T09:17:05Z"
      NotOnOrAfter="2004-12-05T09:27:05Z">
      <saml:AudienceRestriction>
        <saml:Audience>
          https://sp.example.com/SAML2
        </saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement
      AuthnInstant="2004-12-05T09:22:00Z"
      SessionIndex="identifier_3">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>
          urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
        </saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
  </saml:Assertion>
</samlp:Response>
  • その後
    • SAML Response のデジタル署名を検証
    • 内容を処理し、SP でのローカルログオンセキュリティコンテキストを作成
    • SP は RelayState データによって、最初に要求されたリソース URL を呼び戻す。
    • アクセス検査が行われ、検査に合格すると、リソースがブラウザに返される。

SP-Initiated SSO: POST/Artifact Bindings

  • Authentication Request message — HTTP POST Binding でリクエスト
<form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
  <input type="hidden" name="SAMLRequest" value="request" />
  <input type="hidden" name="RelayState" value="value" />
  <input type="submit" value="Submit" />
</form>
POST /SAML2/SSO/POST HTTP/1.1
Host: idp.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn

SAMLRequest=request&RelayState=value
  • Authentication Response message — HTTP Artifact Binding でアサーションを取得
<samlp:ArtifactResolve
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_2" Version="2.0" IssueInstant="2004-12-05T09:22:04Z"
  Destination="https://idp.example.org/SAML2/ArtifactResolution">
  <saml:Issuer>
    https://sp.example.com/SAML2
  </saml:Issuer>
  <!-- an ArtifactResolve message SHOULD be signed -->
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    ...
  </ds:Signature>
  <samlp:Artifact>
    artifact
  </samlp:Artifact>
</samlp:ArtifactResolve>
<samlp:ArtifactResponse
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  ID="identifier_3" InResponseTo="identifier_2"
  Version="2.0" IssueInstant="2004-12-05T09:22:05Z">
  <!-- an ArtifactResponse message SHOULD be signed -->
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    ...
  </ds:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <samlp:Response
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_4" InResponseTo="identifier_1"
    Version="2.0" IssueInstant="2004-12-05T09:22:05Z"
    Destination="https://sp.example.com/SAML2/SSO/Artifact">
    <saml:Issuer>
      https://idp.example.org/SAML2
    </saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion
      ID="identifier_5" Version="2.0"
      IssueInstant="2004-12-05T09:22:05Z">
      <saml:Issuer>
         https://idp.example.org/SAML2
      </saml:Issuer>
      <!-- a Subject element is required -->
      <saml:Subject>
        <saml:NameID
          Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
          user@mail.example.org
        </saml:NameID>
        <saml:SubjectConfirmation
          Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
          <saml:SubjectConfirmationData
             InResponseTo="identifier_1"
             Recipient="https://sp.example.com/SAML2/SSO/Artifact"
             NotOnOrAfter="2004-12-05T09:27:05Z"/>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions
        NotBefore="2004-12-05T09:17:05Z"
        NotOnOrAfter="2004-12-05T09:27:05Z">
        <saml:AudienceRestriction>
          <saml:Audience>
            https://sp.example.com/SAML2
          </saml:Audience>
        </saml:AudienceRestriction>
      </saml:Conditions>
      <saml:AuthnStatement
        AuthnInstant="2004-12-05T09:22:00Z"
        SessionIndex="identifier_5">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
          </saml:AuthnContextClassRef>
        </saml:AuthnContext>
      </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>
</samlp:ArtifactResponse>

IdP-Initiated SSO: POST Binding

もともと SAML v1 でサポートされていた IdP-Initiated SSO ユースケースを引き続きサポート

  • Authentication Request message — N/A
  • Authentication Response message — HTTP POST Binding でレスポンス（リクエストはないが）

ECP Profile

Enhanced Client and Proxy（ECP）プロファイル

  • 特別な機能を持たない市販のブラウザで動作する、

    • 拡張クライアントデバイス
    • ゲートウェイ・プロキシ

    を考慮に入れたプロファイル

※ 昔の携帯電話（ガラケー）など機能の貧弱な DEVICE を想定して
　作成された仕様であるため、昨今はあまり使われないと思う。

ECP Profile Using PAOS Binding

PAOS（Reverse SOAP）という単一のバインディングを定義

  • SOAP ヘッダと SOAP ボディを使用
  • SAML Request、Response をすべて SOAP で処理する。
  • これらの処理は、SP、IdP、ゲートウェイ・プロキシが協調して行う。

補足: 「昨今はあまり使われない」は概ね正しいが、
**学術系フェデレーション（Shibboleth / eduGAIN / 日本の学認）**では、
ブラウザを介さないコマンドライン クライアント
（curl によるデータ取得など）の認証に ECP が現役で使われている。

Single Logout Profile

  • SAML のシングルログアウトのプロファイル
  • シングルログアウト ≒ One アクションで複数の SP & IdP からログアウト出来る的な。
  • 1 つの SP で開始され、IdP の Single Logout Service から
    各 SP の Single Logout Service に要求が送信される。

SP-Initiated Single Logout with Multiple SPs

  • シングルログアウトのメッセージは以下の Binding を使用できる。

    • 同期 — SOAP over HTTP binding
    • 非同期 — HTTP Redirect / HTTP POST / HTTP Artifact bindings

  • Cookie 認証チケットを削除する場合、ブラウザを SP にリダイレクトする必要がある。

    • だったら、最初から HTTP Redirect bindings を使えと言う気もするが、
    • そもそも、SOAP over HTTP binding の場合、どうやって処理するのか？

補足（この疑問への答え）: SOAP（バックチャネル）で SLO を行う場合、
各 SP は自前でセッション ストアを持ち、
<LogoutRequest> に含まれる NameID + SessionIndex で
該当セッションをサーバ側から無効化する。

ブラウザの Cookie は消えないが、サーバ側で無効になっているため無害
（次のリクエストで再認証になる）。
Cookie 自体を消したい場合にはフロントチャネル（Redirect / POST）が要る、
という理解で正しい。

なお、SAML の SLO は実運用でほとんど動かないことが知られている。

  • どれか 1 つの SP が応答しないと全体が中途半端に終わる
  • サードパーティ Cookie 制限で iframe 方式が壊れた
  • SP 側の実装品質にばらつきが大きい

OpenID Connect でも
Front-Channel / Back-Channel Logout が同じ困難を抱えている。
「アクセス トークン／セッションを短命にする」方が現実的な対策である。

Establishing and Managing Federated Identities

Federated Identities を確立・管理する SAML メカニズムの説明（フェデレーションスタイル）

Federation Using Out-of-Band Account Linking

実名

  • SAML 1.0 でサポートされている唯一のスタイル（SAML 2.0 でも引き続きサポート）。
  • SAML 仕様の外でアカウント同期が行われる
    （Hybrid-IdP の Microsoft Entra Connect みたいな）。

Federation Using Persistent Pseudonym Identifiers

永続的な仮名

  • IdP は、永続的な SAML 名識別子を使用して、SP のローカル ID と関連付ける。

  • SAML 2.0 では、<AuthnRequest> に <NameIDPolicy> 要素を提供して、
    SP の動的動作を強制できる。

  • 以下の様なスキーマになるらしい（linked ID で、SP / IdP 間の local ID を紐付ける）

# SP1 local ID SP1 IdP SP1 linked ID IdP1 local ID IdP1 SP IdP1 linked ID
1 XXX IdP1 111 <-> AAA SP1 111
  • （初回時）動的動作で、ユーザーは、
    • SP でローカルの資格情報を提供するよう求められる。
    • 2 つのアカウントを統合したいかどうかを尋ねられる。

Federation Using Transient Pseudonym Identifiers

一時的な仮名

  • 一時的な仮名識別子を使用して、SSO セッションの存続期間中に
    SP のローカル ID と関連付ける。
# SP1 local ID SP1 IdP SP1 linked ID IdP1 local ID IdP1 SP IdP1 linked ID
1 N/A IdP1 111 <-> AAA SP1 111
  • 連携される属性
    • 基本、メンバーシップレベル属性のみで匿名ユーザとして処理できる。
    • 必要に応じて、SAML 属性クエリを属性機関に送信し、ユーザー ID 属性を取得できる。

Federation Termination

既存のフェデレーションの終了。

  • <ManageNameIDRequest>（Termination）を IdP の Manage NameID Service に送信する。
  • これにより、Federation Using Persistent Pseudonym Identifiers の関連付けを解除する。

Use of Attributes

SAML アサーションによる、属性転送機能と、その属性の使い方。

  • プロファイル情報の転送 — IdP から SP へユーザプロファイル情報を伝達して使用する。
  • 属性に基づく承認
    • メンバーシップレベル属性のみで匿名ユーザとして処理できる。
    • IdP と SP は、属性名と値に関する事前の合意を必要とする。

詳細

以下、参考

OASIS

OASIS は「SGML Open」として 1993 年、

主に「研修活動を通じた SGML の採用促進を目的として」結成された、

SGML ツール業者の業界団体。

SAML 1.0

仕様書 内容
Assertions and Protocol［SAML Core］ SAML の Assertions のスキーマと要求／応答プロトコルを定めた仕様
Bindings and Profiles［SAML Bind］ SAML を SOAP と HTTP にバインドする仕組みと SSO プロファイルの規定
Security and Privacy Considerations［SAML Sec］ SAML のセキュリティ要件を考察したもの
Conformance Program Specification［SAML Conform］ SAML の相互運用性を確保するために適合性要件をまとめたもの
Glossary［SAML Gloss］ 用語集

SAML 1.1

SAML 2.0

http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip

Reference

文書 内容
SAMLGloss（用語集） SAML 仕様全体を通して使用される用語を規範的に定義 https://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf
SAMLConform（適合要件） https://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf
SAMLSec（セキュリティ考慮事項） SAML のセキュリティとプライバシーの特性について分析 / 説明 https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf
SAMLErrata（正誤表） SAML V2.0 規格の矛盾や不明確である点の解釈を明確化する
SAMLExecOvr エグゼクティブの概要（非規範的な文書）
SAMLMDV1x SAML V1.x をサポートする SAML エンティティを記述するための V2.0 メタデータ構成体の使用
SAMLMDExtQ クエリ要求者用の SAML メタデータ拡張
SAMLProt3P サードパーティの要求に対する SAML プロトコルの拡張を定義
SAMLX509Attr X.509 認証ベースシステム用の SAML 属性共有プロファイル
SAMLXPathAttr 属性名として XPath URI を使用するための SAML 属性の使用をプロファイル

WSS

http://www.oasis-open.org/committees/wss/

  • WSS — Web Services Security: SOAP Message Security 1.1 (WS-Security 2004).
  • WSSSAML — Web Services Security: SAML Token Profile 1.1. OASIS WSS-TC, February 2006.

XML(W3C)

Else

参考

SAML XML.org

SAML 公式サイト

千歳科学技術大学 > 深町研究室

SAML2.0 日本語情報

医療分野共通認証基盤整備コンソーシアム

  • SAML 実装仕様書 第 1.0 版
    https://www.keieiken.co.jp/medit/pdf/240423/7-data.pdf
    • 第Ⅰ編 概要、用語及び参考文献
    • 第Ⅱ編 フレームワーク（SAML）
    • 第Ⅲ編 機能仕様
    • 第Ⅳ編 実装規約
    • 第Ⅴ編 試験仕様
    • 第Ⅵ編 セキュリティとプライバシに関する考慮事項

用語

# 用語 説明
1 Principal（プリンシパル） ID が認証可能な System Entity（通常は、ユーザ）。
2 Subject（主体） SAML アサーションに含まれるプリンシパル
3 Profile（プロファイル） いくつかの目的のひとつのルールの集合。
4 System Entity（システムエンティティ） コンピュータ / ネットワークシステムのアクティブな要素。
5 Provider（プロバイダ） IdP と SP の総称（System Entity）。
6 Identity Provider(IdP) プリンシパルの ID 情報を作成、維持、及び管理し、他のサービスプロバイダに契約の範囲でプリンシパルの認証を提供するプロバイダ。
7 Service Provider(SP) プリンシパルまたは他の System Entity にサービスを提供するプロバイダ。
8 Attribute Assertion（属性アサーション） Subject の属性に関する情報を伝える Assertion。
9 Authentication Assertion（認証アサーション） Subject に対して行われた認証に関する情報を伝達するアサーション。
10 Authorization Decision Assertion（認可決定アサーション） Subject に対して決定された認可に関する情報を伝達するアサーション。
11 Security Assertion（セキュリティアサーション） セキュリティアーキテクチャのコンテキストで精査されたアサーション。
12 SAML Authority（SAML オーソリティ） Assertion を発行する抽象的な System Entity。
13 Attribute Authority（属性オーソリティ） 属性アサーションを生成する System Entity。
14 Authentication Authority（認証オーソリティ） 認証アサーションを生成する System Entity。
15 Session Authority（セッションオーソリティ） セッションに関連する状態を保持している System Entity の役割 ≒ IdP。
16 Party（当事者） 1 つ以上の不特定のプリンシパル。
17 Asserting Party（アサーティングパーティ） 形式的には、一つ以上の SAML オーソリティをホストする管理ドメイン。非公式には、そのインスタンス。
18 Relying Party(RP)（依拠当事者） 別の System Entity からの情報に基づいて動作が決まる System Entity。
19 Policy Enforcement Point(PEP)（ポリシー実行点） PDP に認可決定要求を送信し、応答で送信される認可決定アサーションを受け付ける。
20 Policy Decision Point(PDP)（ポリシー決定点） PEP から認可決定要求を受け付けて、応答の認可決定アサーションを生成する。
21 SAML Requestor（SAML リクエスタ） サービス要求のために SAML プロトコルを利用する System Entity
22 SAML Responder（SAML レスポンダ） サービス要求に応答するために SAML プロトコルを利用する System Entity
23 SAML Artifact（SAML アーティファクト） 固定サイズの構造化されたデータオブジェクトで間接参照して SAML プロトコルメッセージを取得する
24 Front Channel（フロントチャンネル） UA などの仲介者を経由するエンドポイント
25 Back Channel（バックチャネル） UA などの仲介者を経由しないエンドポイント

移行メモ: 18 の Relying Party の訳が元ページでは「当事者」と
17 の Asserting Party（アサーティングパーティ）と紛らわしかったため、
一般的な訳語である「依拠当事者」に改めた。

機能概要

  • ユーザは UA（ブラウザ）を使用して、SP に対してリソース要求を送信する。
  • SP は、認証されていないユーザからのリソース要求の場合、
    SP に対する <AuthnRequest> の Redirect 要求をユーザの UA に返却する。
  • ユーザの UA は、SSL で IdP に Redirect 要求の <AuthnRequest> を転送。
  • IdP は、ユーザを認証して認証アサーションを作成、
    認証アサーションの Artifact の Redirect 要求をユーザの UA に返却する。
  • ユーザの UA は、Redirect 要求の Artifact を SP に転送する。
  • SP は、IdP に対して <ArtifactResolve> で Artifact を提示して認証アサーションを要求。
  • IdP は、SP に対して <ArtifactResponse> で認証アサーションを応答する。

通信フローの概要

OSSTech

OpenSSO社内勉強会第二回 - SAML -

https://www.osstech.co.jp/_media/techinfo/opensso/osstech-opensso-study-02-saml.pdf

概要

  • SAML とは

    • 認証情報の送受信の方法を規定する
      • フォーマット（XML）
      • 通信プロトコル

  • SSO 実現のための準備 — 信頼の輪（Circle of Trust - CoT）の準備

    • CoT 内の SP に対してのみ SSO 可能
    • IdP-SP 間でお互いを事前に登録（CoT を構成）
    • 一つの CoT 内に複数の IdP が存在することもある

  • アカウント連携

    • NameID というユーザ識別子を IdP と SP 間で共有
    • IdP のアカウントと SP のアカウントを紐付ける
    • NameID には以下のものが使用される
      • メールアドレス / ユーザー名 / ユーザ ID（GUID などの識別子）
      • 仮名：ランダムな文字列によるユーザ識別
      • X.509 の Subject

  • アカウント・ライフサイクル
    サインイン・サインアウト < 連携・解除 < 作成・削除

  • SSO の開始

    • CoT の構成・アカウント連携が完了して、SSO 可能に
    • OpenID Connect の Authorization Code Flow の
      Token リクエストが無い感じ。

詳細

SAML の構成要素

  • アサーション — IdP が発行する XML 形式のユーザに関する証明情報
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0"
  ID="s2907181983bc6f588aeb045fca183d671224506ec" IssueInstant="2009-11-18T08:28:09Z">
  <!-- アサーション発行者 -->
  <!-- アサーションのデジタル署名 -->
  <!-- アサーションの利用条件 -->
  <!-- ユーザ識別子(NameID) -->
</saml:Assertion>
  • プロトコル
<!-- 認証要求（AuthnRequest）: SPがIdPに対して、ユーザの認証情報を要求する -->
<samlp:AuthnRequest ID="xxx" Version="2.0"
  Destination="http://idp.osstech.co.jp/idp/sso">
  <!-- 認証要求情報が入る -->
</samlp:AuthnRequest>
<!-- 認証応答（Response）: IdPがSPにユーザの認証情報を送付する -->
<samlp:Response ID="xxx" Version="2.0"
  Destination="http://sp.osstech.co.jp/sp/sso">
  <saml:Assertion>
    <!-- アサーションが入る -->
  </saml:Assertion>
</samlp:Response>

移行メモ: 元ページの <samlp:Response> の例は、
閉じタグが </samlp:AuthnRequest> になっていたので正した。

  • バインディング

    • メッセージを既存の通信プロトコルに埋め込む方法を規定
    • IdP-SP 間の通信有無で分類すると…
      • 無：HTTP Redirect、HTTP POST
        OAuth 2.0 Form Post Response Modeみたいな
        （SAML では、Request と Response の両方に適用されるのがポイント）
      • 有：HTTP Artifact
        アサーションがクライアントに渡ることがない、
        OpenID Connect の Authorization Code Flow の code みたいな。
        ただ、SAML Response だけでなく、SAML Request にも使えるので、その辺りが異なる。

  • メタデータ

    • CoT の構成、アカウント連携に必要な情報
    • これにより IdP、SP の構築作業が楽になる
    • Google Apps のメタデータの例
<EntityDescriptor entityID="google.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
 <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
 <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
 <AssertionConsumerService index="1"
   Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
   Location="https://www.google.com/a/ドメイン名/acs" />
 </SPSSODescriptor>
</EntityDescriptor>

クラウド時代の シングルサインオン

https://www.osstech.co.jp/_media/techinfo/seminar/hbstudy-20110416-sso.pdf

概要

  • SAML : Security Assertion Markup Language
  • 認証、認可、ユーザ属性情報などを XML で送受信するための仕様
  • Web アプリの "認証処理" を、外部で代行してもらうための仕組み。

移行メモ（正誤）: 元ページは「Secure Assertion Markup Language」
としていたが、正しくは「Security Assertion Markup Language」である。

用語

  • SP / IdP

    • Identity Provider（IdP） — 認証・認可の情報を提供する役割を担う。
      IdP で認証されたユーザーは SP のサービスにアクセスできるようになる。
    • Service Provider（SP） — シングルサインオン対象の Web アプリケーションなど。
      IdP が発行した認証・認可の情報に応じてクライアントにサービスを提供する。

  • トラストサークル（Circle Of Trust）

    • IdP と SP の間で結ばれた信頼関係を意味する。
    • シングルサインオンを実現するためには、
      IdP と SP との間で事前に信頼関係を結んでおく必要がある。
    • IdP-SP 間で、お互いを事前に登録し、お互いの証明書を交換する。
    • 一つのトラストサークル内に複数の IdP が存在することもある

    ※ 同じ言葉でも、他のプロトコルでは意味が違うことがあるので注意

シーケンス

  • 認証シーケンス

    • SP-initiated SSO
      • ユーザーは最初に SP にアクセスし、IdP での認証に成功した後に、再び SP にアクセスする。
      • SP が IdP にリクエストする際に、RelayState というパラメタに遷移先情報を埋め込む。
    • IdP-initiated SSO
      • ユーザーは最初に IdP にアクセスし、IdP での認証に成功した後に SP にアクセスする。
      • IdP が SP にアサーションをレスポンスする際に、
        RelayState というパラメタに遷移先情報を埋め込む。

  • メッセージの送受信方法

    • HTTP Redirect / HTTP POST Binding
      • IdP-SP 間の直接的な通信が発生しない
      • ブラウザが通信を中継する
    • HTTP Artifact Binding
      • アサーションへのリファレンスである Artifact をブラウザを介して
        IdP と SP の間で送受信する。
        IdP と SP は Artifact を利用して直接相手に
        SAML 認証要求 / 認証応答メッセージを問い合わせる。
      • IdP-SP 間の直接的な通信が発生する。
      • Artifact のデータサイズは小さい。

  • リソース・アクセス
    リソースが格納されている URI を格納した RelayState パラメタを使用してリダイレクトする。

ネットワーク構成

  • IdP を社内 LAN に設置 — SP へのアクセスを社内のみからに制限することが可能
  • IdP を DMZ に設置 — 社外から SP にアクセスすることが可能

OpenAMのSAML利用時の認証方式の指定について

https://www.osstech.co.jp/_media/techinfo/openam/saml_authncontext_20150417.pdf

認証方式の指定

<AuthnContextClassRef> を使用する。

  • SP で、利用する IdP に認証方式を指定する。
    • SAML Request の <RequestedAuthnContext> を使用して指定する。
      • <RequestedAuthnContext> は省略可能（多くの SP で使用していない）
      • SP は IdP に対して Authentication Context を通知できる。
<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  ID="XXXX" Version="2.0" IssueInstant="2015-04-13T04:59:38Z"
  Destination="xxxxxx" ForceAuthn="false" IsPassive="false"
  ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  AssertionConsumerServiceURL="XXXXX">
  <samlp:RequestedAuthnContext
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact">
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    </saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

  • <RequestedAuthnContext> の構成

    • <AuthnContextClassRef> 要素 — Authentication Context Class を一つ以上記述
    • Comparison 属性 — 比較手法を指定（exact（既定値）、minimum、maximum、better）

  • IdP で、SP に実施した認証方式に応答する。

    • これにより、SP は、IdP でどのような認証が行われたか判断できる。
    • SAML Response の Assertion には必須(MUST) の要素
      AuthnStatement -> AuthnContext -> AuthnContextClassRef

OpenAMの実装を把握する

  • OpenAM を SP として構築した場合

    • SAML Request の <RequestedAuthnContext> に Authentication Context Class を指定可能
      • 既定値では、PasswordProtectedTransport を指定。
      • QueryString で AuthnContextClassRef を指定することもできる。
      • 「|」（パイプ）で区切ることで複数の <AuthnContextClassRef> を指定することが可能
    • SAML Response と SAML Request の Authentication Context Class を比較
      • 指定した Authentication Context Class とマッチしなかった場合はエラー
      • デフォルト設定では PasswordProtectedTransport のみ許容。

  • OpenAM を IdP として構築した場合

    • SAML Request の Authentication Context Class を、
      • 既定値は、PasswordProtectedTransport として解釈。
      • デフォルト設定では PasswordProtectedTransport のみ許容
    • SAML Response の Authentication Context Class は、
      Assertion -> AuthnStatement -> AuthnContext -> AuthnContextClassRef に指定される。

Cybozu

サイボウズエンジニアのブログ

SAML は Security Assertion Markup Language の略で、OASIS によって策定された、
異なるセキュリティドメイン間で、認証情報を連携するための XML ベースの標準仕様。

用語

  • 認証情報を提供する側を、Identity Provider（IdP）
  • 認証情報を利用する側を、Service Provider（SP）

仕様

仕様 内容
Core 認証情報を表す XML のスキーマ（Assertions）と、メッセージ交換のプロトコル（Protocols）を定義。
Bindings メッセージを実際の通信プロトコル（HTTP など）にマッピングする方法を定義。
Profiles 特定のユースケースを実現するための組み合わせ方（Assertions / Protocols / Bindings）を定義。
Metadata IdP や SP に関する情報を表現するための XML のスキーマを定義（IdP と SP の信頼関係を構築）。

シーケンス

Web Browser SSO Profile のシーケンス

  • ユーザーが SP にアクセスする
  • ユーザーが未ログイン状態な場合、SP が認証要求メッセージを生成する
  • ユーザーが SP から認証要求メッセージを受け取り、それを IdP に送る
  • IdP が認証要求メッセージを受け取り、ユーザーを認証する
  • IdP が認証応答メッセージを作成する
  • ユーザーが IdP から認証応答メッセージを受け取り、それを SP に送る
  • SP が認証応答メッセージを受け取り、検証する（検証項目の一部）
    • Version 属性の評価
    • <Status> 要素の評価
    • <SubjectConfirmation> 要素の Method 属性の評価
    • <SubjectConfirmationData> 要素の内容の評価
    • <Conditions> 要素の評価
    • <AudienceRestriction> 要素の評価
    • <Assertion> 要素の署名の検証
  • メッセージの内容に問題がない場合、ユーザーは SP にログインできる

要件

Web Browser SSO Profile の要件

  • IdP との信頼関係の構築機能の設計

    • SP に信頼する IdP を登録する。
      • IdP が認証要求メッセージを受け取る URL
      • IdP が認証応答メッセージの署名の検証に使用する公開鍵
      • SP からログアウトした後に遷移する URL（IdP のログアウト用 URL へのリダイレクト）
    • IdP が信頼する SP の登録

  • メッセージ処理機能の設計

    • 認証要求メッセージの作成
    • 認証要求メッセージを IdP に送る
      • HTTP Redirect Binding : Deflate エンコード -> Base64 エンコード -> URL エンコード
      • HTTP POST Binding : Base64 エンコード -> URL エンコード
    • IdP が発行した認証応答メッセージを受け取る（同上）
    • 認証応答メッセージを検証する（前掲の検証項目）

cybozu.com ヘルプ

SP Initiated な Web Browser SSO Profile

SAML リクエストと SAML レスポンスには、次のバインディングを使用する。

  • SAML リクエスト：HTTP Redirect Binding
  • SAML レスポンス：HTTP POST Binding

設定

  • IdP に SP を登録する

    • 手入力する場合
      • エンティティ ID（URL の最後に「/」（スラッシュ）をつけないでください。）
      • SP のエンドポイント URL
      • ユーザーを識別する要素：NameID
    • メタデータファイルを使用する場合

  • SP に IdP を登録する

    • SP で SAML 認証を有効化し、
    • SP に IdP の情報を設定。
      • IdP の SSO エンドポイント URL（HTTP-Redirect）
      • SP からのログアウト後に遷移する IdP の URL
      • IdP が署名に使用する公開鍵の証明書

Wikipedia

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

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

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally