MS_SAMLProfiles

SAML Profiles

• 戻る（SAMLの仕様を読む。）
  • SAML Profiles
  • SAML Bindings
  • SAML Core

概要

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

• ターゲットは SP Initiated な Web Browser SSO Profile に絞る。
• ココに書いた情報は、SAML の Profiles の範囲。

Introduction

• 以下の使用を定義する

  • 通信プロトコル
  • アサーション
  • 要求 / 応答メッセージ
  • また、SAML 属性値の構文および命名規則

• 関連仕様

  • SAMLCore（SAML Core）
    SAML アサーションと要求応答プロトコルメッセージの仕様を定義
  • SAMLBind（SAML Bindings）
    SAML プロトコルメッセージの基礎となる
    通信およびメッセージング・プロトコルへのバインディングの仕様を定義
  • SAMLConform
    SAML 2.0 を構成するすべての仕様をリストしている。

Profile Concepts

• SAML アサーションをフレームワークまたはプロトコルに
  埋め込む方法およびそれらから抽出する方法を記述する一連の規則を概説

  • 様々な種類のプロファイルの選択されたセットを詳細に指定。
  • 独自に実装された製品が相互運用できるようにする。

• SAML に固有のその他の用語と概念については、SAML 用語集 [SAMLGloss] を参照。

Notation

• 技術文書中での Shall / Should / May
• この仕様では従来の XML 名前空間プレフィックスが使用される。
• , etc.

Specification of Additional Profiles

追加仕様策定のガイドラインなど（割愛）

Confirmation Method Identifiers

• <SubjectConfirmation> 要素は、

  • 特定の Profile の Context 内で、SP によって使用される。
  • Message が「Assertion 内の Subject に関連付けられている
    システムエンティティから送信された。」ことを確認する。

• 子要素

  • Method 属性 — SP が使用すべき特定の方法（Assertion の検証方法）
  • <SubjectConfirmationData> — 証明書やキーなどの追加情報

移行メモ: 元ページは「子要素」として <ConfirmationMethod> を
挙げていたが、SAML 2.0 では**Method は <SubjectConfirmation> の属性**である
（<ConfirmationMethod> 要素は SAML 1.x の書式）。

Bearer

• 持参人切符

URI: urn:oasis:names:tc:SAML:2.0:cm:bearer

• Assertion の Subject ≒ Assertion の所有者

<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
  <SubjectConfirmationData
    InResponseTo="_1234567890"
    Recipient="https://www.serviceprovider.com/saml/consumer"
    NotOnOrAfter="2004-03-19T13:27:00Z"/>
</SubjectConfirmation>

Holder of Key

• 記名式切符

URI: urn:oasis:names:tc:SAML:2.0:cm:holder-of-key

• <SubjectConfirmationData> 要素内に 1 つ以上の <ds:KeyInfo> 要素が必要。

<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
  <SubjectConfirmationData xsi:type="saml:KeyInfoConfirmationDataType">
    <ds:KeyInfo>
      <ds:KeyName>By-Tor</ds:KeyName>
    </ds:KeyInfo>
    <ds:KeyInfo>
      <ds:KeyName>Snow Dog</ds:KeyName>
    </ds:KeyInfo>
  </SubjectConfirmationData>
</SubjectConfirmation>

補足: Holder of Key は、
アサーションの提示者が対応する秘密鍵を持っていることを別途証明する方式で、
盗まれても使えない（＝ 記名式）という利点がある。
OAuth の DPoP / mTLS 送信者制約トークンと同じ発想。

ただし SAML の Web SSO では、
ブラウザに鍵の証明をさせる手段がないためほぼ使われない。
実運用はほぼすべて bearer である。

Sender Vouches

URI: urn:oasis:names:tc:SAML:2.0:cm:sender-vouches

• アサーションの使用のコンテキストに関して他に情報がないことを示す。
• SP は他の手段を利用し、アサーションをさらに処理すべきかどうかを決定する必要がある。

Web Browser SSO Profile

• Web SSO をサポートするために定義されている。

• SAMLCore では、次のように定義されている。

  • オリジナルの SAML 要件文書の「シナリオ 1-1」をサポートし、Web SSO をサポート。
  • 拡張クライアントをサポートするために追加の Web SSO プロファイルが定義されている。
  • シングルログアウトおよび名前識別子管理プロトコルのプロファイルは、
    フロントチャネルとバックチャネルの両方のバインディングで定義されている。

• Cookie を使用した IdP の検出用に追加のプロファイルが定義されている。

Required Information

#	項目	説明
1	Identification	urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser
2	Contact information	security-services-comment@lists.oasis-open.org
3	SAML Confirmation Method Identifiers	SAML 2.0 "bearer" confirmation method identifier, urn:oasis:names:tc:SAML:2.0:cm:bearer
4	Updates	SAML V1.1 の browser artifact / POST profiles / bearer confirmation method.

Profile Overview

図は割愛、以下シーケンス（SP-initiated SSO）。

1. HTTP Request to SP

   • SP でセキュリティ保護されたリソースに対する HTTP 要求を行う。
   • この時点では、SP 上のセキュリティ・コンテキストは使用しない（存在しない）。

2. SP Determines IdP

   • IdP を特定する（実装依存）
   • SAML Identity Provider Discovery Profile を使用してもイイ。

3. <AuthnRequest> issued by SP to IdP
   以下は使用できる Binding。

   • HTTP Redirect binding
   • HTTP POST binding
   • HTTP Artifact binding

4. IdP identifies Principal
   簡単に言うと、認証してログインセッションを確立する的な。

5. IdP issues <Response> to SP

   • Assertion か Error を返す。
   • 以下は使用できる Binding。
     • HTTP POST binding
     • HTTP Artifact binding

6. SP grants or denies access to Principal
   簡単に言うと、ログインセッションを確立して、ユーザにリソースを返す。

※ IdP-initiated SSO は、5 番目の手順から。

Profile Description

EndPoint については、既に説明済み。

• Single Sign-On Service
• Assertion Consumer Service

以下では、Profile Overview の追加項目のみ説明。

HTTP Request to SP

• Profile 交換を元の要求と関連付けるために SP が
  使用することができる RelayState メカニズムを提供する。

• Profile の使用がそのような Privacy 対策を必要としない場合を除き、
  SP は RelayState の値にできるだけ少ない要求を公開する必要がある（SHOULD）。

SP Determines IdP

• 基本は、SP が Request を送信する IdP を決定する。

• また、SP は、

  • このサービスに <AuthnRequest> を発行して IdP に中継するか、
  • または中間サービスに依存して <AuthnRequest> メッセージを発行する

  ことがある。

<AuthnRequest> Is Issued by SP to IdP

• この HTTP の通信には、TLS を使用する。

• SP によって選択された Binding に基づき、

  • SSO Service の場所が決定される。
  • SAMLMeta を Binding 選択に使用することができる。

• <AuthnRequest> を送信するために

  • UA による HTTP Request に応答し、
  • 使用されている Binding に応じた HTTP レスポンスを UA に返し、
  • IdP の SSO Service に配信される。

• 機密性とメッセージの完全性を維持することが推奨される。

  • <AuthnRequest> メッセージに署名することができる。
  • HTTP Artifact binding の場合は、Artifact が間接参照されたとき
    リクエスト発行者を認証するための代替手段も提供される。

• IdP は <AuthnRequest> メッセージを処理する。
  IsPassive 属性が含まれている場合、
  UA とのその後のやりとりを制限する可能性がある。

IdP Identifies Principal

IdP はプリンシパルのアイデンティティを確立

• <AuthnRequest> 要素の ForceAuthn 属性が true の場合、既存ではなく、
  新たにプリンシパルのアクティブ・セッションを確立するように IdP に義務付ける。

• SAML Request の <RequestedAuthnContext> 要素に含まれる
  任意の要件に従って、UA を認証するための任意の手段を使用する。

IdP Issues <Response> to SP

IdP は、<AuthnRequest> の成功または失敗にかかわらず、UA 経由で、
指定の Binding と Protocol で Assertion Consumer Service に応答する。

• この HTTP の通信には、TLS を使用する。

• SP は、

  • 使用する SAML Binding
  • Assertion Consumer Service の場所

  を示すことができる。

• Assertion Consumer Service の場所は、
  SAMLMeta を使用して決定される場合がある。

• 機密性とメッセージの完全性を維持することが推奨される。

  • <Response> 内の <Assertion> 要素は、署名することができる。
  • HTTP POST binding が使用されている場合は署名が必要。
  • HTTP Artifact binding が使用されている場合は必要に応じて署名。

SP Grants or Denies Access to User Agent

• SP は、<Response> の <Assertion> 要素を処理しなければならない。
• SP は、
  • 新たにプリンシパルのアクティブ・セッションを確立する。
  • リソースへのアクセスを許可または拒否する。

Use of Authentication Request Protocol

• Authentication Request protocol について。

• アクターの名称

  • SP は Issuer と RP であり、
  • プリンシパルは Presenter、要求された Subject、および confirming entity である。
  • IdP の裁量で、追加の RP または confirming entity がある場合がある。

<AuthnRequest> Usage

• <AuthnRequest> には <Issuer> 要素が必須

  • <Issuer> 要素の Format 属性は、省略するか、
    urn:oasis:names:tc:SAML:2.0:nameid-format:entity の値を指定。

• SP は、

  • IdP のサインアップを許可する場合、<AuthnRequest> に、
    AllowCreate 属性を "true" に設定した <NameIDPolicy> 要素を含める。
  • ID を指定する場合、<AuthnRequest> に、<Subject> 要素を含める。
    （ただし、<SubjectConfirmation> 要素を含んではいけない。）
  • 必要に応じて、<AuthnRequest> メッセージを署名（認証）する。
    • HTTP Artifact binding が使用されている場合、オプションで署名（認証）。
    • その他の Binding によって許可されている任意のメカニズムが使用されてもよい。
  • SAMLMeta 内の必要な属性または必須の属性に関する情報を参照する、
    AttributeConsumingServiceIndex 属性を含めることができる。

• IdP は、

  • <AuthnRequest> が署名（認証）されていない場合、
    および / または完全性が保護されていない場合、
    その中の情報は勧告を除いて信頼してはならない。
  • 以下は、署名（認証）に関わらず、サービスに属するものとして検証する。
    • AssertionConsumerServiceURL 属性
    • AssertionConsumerServiceIndex 属性
  • AttributeConsumingServiceIndex 属性を含めることができる。
    IdP はこれを無視するか、または独自の判断で他の属性を送信することができる。

補足: 「署名の有無に関わらず
AssertionConsumerServiceURL を検証する」という規定は特に重要である。
未署名の要求でも「メタデータに登録済みの ACS URL であること」を
必ず確認しないと、任意の URL にアサーションを送らされる
（SAML Protocolsを参照）。

<Response> Usage

• 要求を満たすことができない、または満たさない <AuthnRequest> に対し、
  適切なエラーステータスコードを含み Assertion を含まない <Response> で応答する。

• 要求が成功した場合（または応答が要求に関連付けられていない場合）
  <Response> 要素は以下に従う。

  • <AuthnRequest> に応答している場合、
    <AuthnRequest> の ID 属性が <Response> の
    InResponseTo 属性と一致する必要がある。

  • <Issuer> 要素

    • 省略可能
    • しかし、IdP の一意識別子は必要。
    • Format 属性は、省略するか、
      urn:oasis:names:tc:SAML:2.0:nameid-format:entity の値を指定。

  • <Assertion> 要素 — 必須、1 つ以上必要

  • <Assertion> 要素の <Issuer> 要素

    • Format 属性は、省略するか、
      urn:oasis:names:tc:SAML:2.0:nameid-format:entity の値を指定。

  • <AuthnStatement> 要素

    • 必須、<Assertion> セットに対して 1 つ以上必要
    • <Subject> の <SubjectConfirmation> 要素が必要で、
      Method 属性には、urn:oasis:names:tc:SAML:2.0:cm:bearer の値が必要。
    • <SubjectConfirmation> の <SubjectConfirmationData> 要素が必要で、
      Recipient と NotOnOrAfter 属性が必要で、Address 属性を含む可能性がある。
      NotBefore 属性は含んではならない。
    • Single Logout profile をサポートする場合、SessionIndex 属性が必要になる。
    • また、AttributeStatement など、他の Statement と、
      その確認方法が、IdP の裁量で Assertion に含まれる可能性はある。

<Response> Message Processing Rules

SAML binding に関係なく、SP は次のことをしなければならない。

• Assertion または Response に存在する署名を確認する。

• <SubjectConfirmationData> の

  • Recipient 属性が、<Response> または Artifact が
    配信された Assertion Consumer Service の URL と一致することを確認する。
  • NotOnOrAfter 属性を確認し、有効期間の終了時点に達していないことを確認する。
  • InResponseTo 属性が、<AuthnRequest> の ID 属性と等しいことを確認する。
  • Address 属性が含まれている場合、SP は UA のアドレスをチェックしてもよい（MAY）。

• ローカルログオンセキュリティコンテキストを確立するために使用しない。

  • 有効ではない Assertion
  • Subject 確認要件を満たすことができない Assertion

• <AuthnStatement> の SessionNotOnOrAfter 属性が含まれている場合、
  この時間に達したらローカルログオンセキュリティコンテキストを破棄する必要がある。

補足（SP 側の検証チェックリスト）: 上の規定に、
SAML Assertions 側の要件を合わせると、
SP が必ず行うべき検証は次のとおりになる。どれ一つ省いてはならない。

#	検証項目
1	<Assertion>（または <Response>）の署名が、信頼済みの IdP 鍵で検証できる
2	署名アルゴリズムが許容範囲（SHA-1 は拒否）
3	<Issuer> が期待する IdP の EntityID
4	<AudienceRestriction> に自分の EntityID が含まれる
5	<Conditions> の NotBefore / NotOnOrAfter（時刻ずれ許容つき）
6	<SubjectConfirmationData> の Recipient が自分の ACS URL
7	同 NotOnOrAfter が未経過
8	同 InResponseTo が自分の出した <AuthnRequest> の ID
9	<Response> の Destination が自分の ACS URL
10	Assertion の ID を記録し、再利用（リプレイ）を拒否
11	署名を検証したノードから値を取り出す（XSW 対策）

<Assertion> と <Response> のどちらに署名があるかは IdP 依存である。
「どちらか一方は必ず署名されていること」を要求し、
署名されていない側の値を信用しないのが安全な実装である。

Artifact-Specific <Response> Message Processing Rules

• HTTP Artifact Binding が <Response> の配信に使用される場合、
  Artifact Resolution profile を使用した artifact の間接参照は、
  相互に認証され、完全性が保護され、機密である必要がある。

• IdP は、<Response> メッセージが発行された SP だけに
  <ArtifactResolve> 要求の結果としてメッセージが渡されるようにする。

• Artifact を間接参照するために使用される Binding または署名
  のいずれかを使用して、SP を認証し、メッセージを保護できる。

POST-Specific Processing Rules

HTTP POST Binding を使用して <Response> を配信する場合は、

• 同封の Assertion に署名する必要がある。

• SP は、<SubjectConfirmationData> の NotOnOrAfter 属性に基づいて
  Assertion が有効であると見なされる期間に渡って使用済み ID 値のセットを
  維持することで、Assertion が再生されないようにする必要がある。

補足（リプレイ防止の実装）: 「使用済み ID のセットを維持する」とは、
具体的には <Assertion> の ID を、その有効期限まで保存し、
同じ ID が再び来たら拒否するということ。

有効期限（通常 5 分程度）を過ぎたエントリは捨ててよいので、
有効期限つきの分散キャッシュ（Redis など）が向く。
Web サーバを複数台で運用する場合、
プロセス内メモリに持つとロードバランサ次第でリプレイが通るので注意。

Unsolicited Responses

IdP は、SP に Unsolicited <Response> メッセージの配信を開始してもよい（MAY）。

• <Response> も <SubjectConfirmationData> 要素も
  InResponseTo 属性を含んではいけない。

• メタデータで <md:AssertionConsumerService> が提供される場合、
  <Response> または artifact を、ここで指定された SP のエンドポイントに配信すべき。

• 特に言及するのは、

  • IdP が、SP との相互の合意に基づいて、UA とのその後の対話を
    どのように処理するかを示す Binding 固有の RelayState パラメタを含んでよい。
  • RelayState パラメタの値は、SP のリソースの URL であるかもしれない。
  • SP は、応答の処理に成功した後に UA を送信するデフォルトの場所を
    指定することによって、Unsolicited <Response> メッセージを処理する準備をするべき。

補足: これが IdP 開始 SSO の規定である。
InResponseTo が無いため CSRF 対策が効かず、
セキュリティ上は推奨されない（SAMLの仕様を読む。を参照）。
対応が必須の場合も、リプレイ防止（Assertion ID の記録）は必ず実装すること。

Use of Metadata

• <md:IDPSSODescriptor> 要素の

  • <md:SingleSignOnService> 要素
    このプロファイルを使用して SP が IdP に要求を送信できるエンドポイントの場所を記述。
  • WantAuthnRequestsSigned 属性
    要求メッセージが署名されるという要件を文書化してもいい（MAY）。

• <md:SPSSODescriptor> 要素の

  • <md:AssertionConsumerService> エンドポイント要素
    IdP が SP に応答を送信する際の
    サポートされている Binding とインデックス付きエンドポイントの場所の情報。
    • index 属性 — エンドポイントを区別するために使用される。
    • isDefault 属性 — 要求で指定されていない場合に使用するエンドポイントを指定する。
  • <md:AttributeConsumingService> エンドポイント要素 — 属性要件のセット
    • index / isDefault 属性（同上）
  • AuthnRequestsSigned 属性
    要求メッセージが署名されるという要件を文書化してもいい（MAY）。
  • WantAssertionsSigned 属性
    • Profile で配信される Assertion 署名要件の文書化が可能。
    • IdP はこれに義務付けられないが、
      未署名の Assertion が不十分になる可能性を認識する。
    • 特定の Binding の使用によって課される署名に関する要件に加えて行われる。

• 署名・暗号化

  • use 属性が signing — <md:KeyDescriptor> 要素を使用して、
    署名に使用するキーを文書化。
  • use 属性が encryption — <md:KeyDescriptor> 要素を使用して、
    暗号化アルゴリズムと公開キーを文書化。

• <md:ArtifactResolutionService> 要素
  要求 / 応答メッセージに HTTP Artifact Binding を使用する場合、
  1 つ以上のエンドポイント要素を提供する必要がある。

• 以下も記述でき、認証交換中にサポートできるかどうかは
  ポリシーと IdP の裁量に依存する。

  • <md:NameIDFormat> 要素 — 特定の名前識別子の形式
  • <md:AttributeProfile> 要素 — 属性プロファイル
  • <saml:Attribute> 要素 — 特定の属性と値

移行メモ（正誤）: use 属性の値は元ページで sign / encrypt と
なっていたが、スキーマ上の値は signing / encryption である。

また、<md:NameIDFormat> 等の 3 要素は元ページでは
<md:ArtifactResolutionService> の子項目として並んでいたが、
これらは <md:IDPSSODescriptor> 直下の要素であるため、階層を分けた。

参考

https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

1 Introduction
1.1 Profile Concepts
1.2 Notation

2 Specification of Additional Profiles
2.1 Guidelines for Specifying Profiles
2.2 Guidelines for Specifying Attribute Profiles

3 Confirmation Method Identifiers
3.1 Holder of Key
3.2 Sender Vouches
3.3 Bearer

4 SSO Profiles of SAML
4.1 Web Browser SSO Profile
4.1.1 Required Information
4.1.2 Profile Overview
4.1.3 Profile Description
4.1.4 Use of Authentication Request Protocol
4.1.5 Unsolicited Responses
4.1.6 Use of Metadata

4.2 Enhanced Client or Proxy (ECP) Profile
4.2.1 Required Information
4.2.2 Profile Overview
4.2.3 Profile Description
4.2.4 ECP Profile Schema Usage
4.2.5 Security Considerations

4.3 Identity Provider Discovery Profile
4.3.1 Common Domain Cookie
4.3.2 Setting the Common Domain Cookie
4.3.3 Obtaining the Common Domain Cookie

4.4 Single Logout Profile
4.4.1 Required Information
4.4.2 Profile Overview
4.4.3 Profile Description
4.4.4 Use of Single Logout Protocol
4.4.5 Use of Metadata

4.5 Name Identifier Management Profile
4.5.1 Required Information
4.5.2 Profile Overview
4.5.3 Profile Description
4.5.4 Use of Name Identifier Management Protocol
4.5.5 Use of Metadata

5 Artifact Resolution Profile
6 Assertion Query/Request Profile
7 Name Identifier Mapping Profile
8 SAML Attribute Profiles
8.1 Basic Attribute Profile

補足（Identity Provider Discovery Profile は現在動かない）:
このプロファイルは「共通ドメインの Cookie」で
「ユーザが直近どの IdP を使ったか」を SP に伝える仕組みだが、
サードパーティ Cookie の廃止により事実上機能しない。

現在は次のいずれかで代替される。

• ホーム レルム ディスカバリ（HRD） — メールアドレスのドメイン部で IdP を決める
• SP 側での明示的な IdP 選択画面
• テナント別の URL（https://sp.example.com/t/contoso/login など）

---

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