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

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

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

SAML 要求 / 応答メッセージ交換の

• 標準メッセージング
• 通信プロトコルへのマッピング

は、SAML Bindings と呼ばれる。

• 特定の通信プロトコル <FOO> にマッピングした
  SAML Bindings は、SAML <FOO> Binding と呼ばれる。

• この仕様の目的は、

  • SAML 準拠ソフトウェアが確実に相互運用できるように、
    Binding を十分に詳細に指定すること。
  • 特に指定のない限り、Binding は、以下から派生したメッセージとその送信をサポートする。
    • samlp:RequestAbstractType
    • samlp:StatusResponseType

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

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

SAML 規格の一部として指定されている Binding を定義

SAML 規格として定義された全ての Binding の規範的特性

• 幾つかの Binding は、状態情報を保存し伝達
  するための RelayState メカニズムを定義する。

• SAML 要求メッセージに RelayState データが付随している場合、

  • レスポンダは RelayState メカニズムもサポートする Binding を使用して
    応答しなければならず、
  • 応答には、要求で受け取った正確な RelayState データを
    対応する RelayState に含める必要がある。

補足（RelayState の使い方）: RelayState は
OAuth の state に似ているが同じではない。

	SAML	OAuth
CSRF 対策	InResponseTo（SAML Protocols）	state
遷移先の保持	RelayState	state（に相乗りすることが多い）

RelayState の値は IdP を素通りして返ってくるだけであり、
完全性保護がない。そのため次の 2 点が重要である。

• URL を直接入れない。入れると
  オープン リダイレクタになる（任意サイトへ飛ばせる）。
  サーバ側に遷移先を保存し、RelayState には不透明なキーだけを入れる。
• 80 バイト制限があるため、そもそも URL は入りきらないことが多い。

• 特に明記しない限り、セキュリティステートメントはすべての Binding に適用される。
• Binding は、セキュリティ機能について追加のステートメントを出すこともある。

補足（最新化）: 「SSL 3.0 または TLS 1.0」は 2005 年当時の記述。
現在は TLS 1.2 以上（SSL/TLS）が必須である。
SSL 3.0 は RFC 7568、TLS 1.0 / 1.1 は RFC 8996 で禁止・非推奨とされた。

展開の前に、脆弱性について分析すべき。

• 以下のコンテキスト上での、プロトコル交換 / 展開環境

• メカニズムの組合せ（認証 / メッセージの完全性 / メッセージの機密性）

• 詳細な議論については以下を参照

  • 特定のプロトコル処理規則 [SAMLCore]（SAML Core）
  • SAML セキュリティ問題文書 [SAMLSecure]

SAML Protocol メッセージを URL パラメタで送信できるメカニズムを定義

• URL パラメタで XML メッセージを送信するには、

  • 特殊エンコードが必要で
  • 文字列長の制限がある。

• HTTP POST Binding または HTTP Artifact Binding

  • 2 つの異なる Binding を組み合わせて要求 / 応答メッセージを送信可能。
  • HTTP Redirect Binding より大規模で複雑なメッセージを送信可能。

UA を仲介者として使用して通信する必要がある場合を対象とする。

RelayState が含まれてもよい。

• 値は長さが 80 バイトを超えてはならない。

• 他の保護から独立してエンティティによって完全性保護されるべき。

• 値は長さ制限から、署名は現実的でないので、
  チェックサム・擬似乱数を使用して改ざんを確認。

• SAML リクエスタが SAML 要求メッセージに RelayState データを

  • 添付する場合、SAML レスポンダは、
    • RelayState をサポートする Binding を選択して応答する必要がある。
    • 受け取ったデータを、そのままレスポンスの中の対応する
      RelayState パラメタに入れる。
  • 添付しない場合、SAML レスポンダは、
    Profile または事前の合意の使用に基づいて RelayState データを含めることができる。

XML を URL にエンコードする方法を SAMLEncoding に指定する。

• 既定値は、urn:oasis:names:tc:SAML:2.0:bindings:URL-Encoding:DEFLATE
• この Binding をサポートする全てのエンドポイントは DEFLATE Encoding のサポートが必要。
• コチラの例が参考になる。

DEFLATE 圧縮方式を介して URL にエンコード（署名されたコンテンツを含む SAML は対象外）

• シリアル化手順

  1. <ds:Signature> 要素がある場合、コレを削除（メッセージ長的に問題）
  2. 明記されていないが、先ず、XML 宣言のエンコーディングでエンコード。
  3. DEFLATE 圧縮メカニズムで SAML を圧縮する。
  4. オクテットを Base64 エンコードで文字列化する
     （改行または他の空白は結果から取り除く）。
  5. Base64 を URL エンコードし、クエリ文字列の
     SAMLRequest パラメタとして URL に追加。
  6. RelayState を URL エンコードし、クエリ文字列の
     RelayState パラメタとして URL に追加。
  7. 署名を追加する。

     • 署名アルゴリズム識別子 [XMLSig] の URI 表現を
       URL エンコードし、クエリ文字列の SigAlg パラメタとして URL に追加。

       アルゴリズム	URI
       DSAwithSHA1	http://www.w3.org/2000/09/xmldsig#dsa-sha1
       RSAwithSHA1	http://www.w3.org/2000/09/xmldsig#rsa-sha1
       RSAwithSHA256（推奨）	http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

     • 次のいずれかの方法でクエリ文字列を構築する。

       SAMLRequest=value&RelayState=value&SigAlg=value
       SAMLResponse=value&RelayState=value&SigAlg=value
       

     • 上記のクエリ文字列を ASCII エンコードし、署名アルゴリズムで署名する。

     • オクテットを Base64 エンコードで文字列化する。

     • Base64 を URL エンコードし、クエリ文字列の
       Signature パラメタとして URL に追加。

補足（最新化）: 仕様が例示するのは SHA-1 系だが、
SHA-1 は使用しない。rsa-sha256（上表）を用いること。

• ポイント

  • 仕様に明記されていないが、
    XML → UTF-8 エンコーディング → DEFLATE 圧縮とするらしい。

    • クラウドとの認証連携 | Think IT（シンクイット）
      https://thinkit.co.jp/story/2011/02/18/1999?page=0%2C2

      ヘッダも必要（UTF-8 で）。

      <?xml version="1.0" encoding="UTF-8"?>

    • EZ-NET: XmlDocument を XML 宣言付きの整形された String に変換する

      XmlWriterSettings を使用して、UTF-8、インデント無しを指定。

    • C# - SAMLリクエストについて｜teratail
      https://teratail.com/questions/50890

      ヘッダに合わせて、（UTF-8 で）エンコーディングする。

      // × byte[] samlRequestBytes = Encoding.Unicode.GetBytes(samlRequestXmlDoc.InnerXml);
      // 〇
      byte[] samlRequestBytes = Encoding.UTF8.GetBytes(samlRequestXmlDoc.InnerXml);

  • URL エンコードは、デフォルトの方式以外のものが用いられている可能性がある。
    このため、メタデータを用いてサポートする URL エンコード方法を提示する。

  • クエリ文字列パラメタ順は、Binding によって規定されていないが、
    署名を検証する場合は、前述の「クエリ文字列を構築」順序と合っているか確認する。

  • クエリ文字列パラメタ値が空文字列の場合は、パラメタ自体を署名の演算から除外する。

補足（署名検証で最も間違えやすい点）: HTTP Redirect Binding の署名は
**XML署名ではなく、
クエリ文字列そのものに対する署名（デタッチ署名）**である。

検証側は「受け取った生のクエリ文字列」を使わなければならない。
Web フレームワークが URL デコードした値から再構築すると、

• エンコード方式の違い（+ と %20、大文字小文字の 16 進）
• パラメタの並び順

によって署名が一致しなくなる。
ASP.NET なら Request.QueryString の再構築ではなく、
Request.Url.Query から自分で切り出すこと。

また、SigAlg を鵜呑みにしない。
メタデータで合意した鍵とアルゴリズムで検証する
（JWS の alg と同じ問題である）。

• HTTP Redirect による OAuth Dance 的なシーケンスの説明

• ポイントは、<samlp:AuthnRequest> 要素の IsPassive 属性が

  • true の場合、IdP はユーザとの対話が禁止される
  • false の場合、IdP はユーザとの対話が許される

  と言う点のみ。

移行メモ（正誤）: 元ページは true / false の両方について
「IdP はユーザとの対話が禁止される」と書かれていた（同文の重複）。
IsPassive="false"（既定値）なら対話してよいが正しい。

IsPassive="true" は「画面を出さずに、既存セッションだけで答えろ」
という意味で、満たせない場合 IdP は
urn:oasis:names:tc:SAML:2.0:status:NoPassive を返す。
iframe 内でのサイレント再認証などに使われる
（OpenID Connect の prompt=none に相当）。

HTTP レスポンダ（SAML レスポンダ）は、以下のヘッダーフィールドを含める。

Cache-Control: no-cache, no-store
Pragma: no-cache

• UA の仲介者が存在するため、認証、完全性、機密性について
  トランスポート層を頼ることができないので必要に応じて署名を行う。

  • 署名を介したメッセージレベルの認証と完全性の保護に依存。
  • UA の仲介者に対するメッセージの機密性はサポートしない。

• 機密性は OPTIONAL で、必要な場合は、TLS を使用する。

• クエリ文字列パラメタは、HTTP の Referer ヘッダや、HTTP ログに
  公開される可能性がある。

補足: 「クエリ文字列がログや Referer に残る」ことは
Redirect Binding をレスポンス（アサーション）に使わない理由でもある。
アサーションが URL に載ると、
プロキシ・ログ・ブラウザ履歴に認証結果が残ってしまう。

Web Browser SSO Profile が
「Request は Redirect、Response は POST」という組み合わせを
定番としているのはこのためである。

SAML レスポンダが、要求とメッセージ交換を行うことを拒否する場合、

• SAML 応答メッセージ
  第 2 レベルの <samlp:StatusCode> 要素で以下の値を返す。

  urn:oasis:names:tc:SAML:2.0:status:RequestDenied
  

• HTTP 応答メッセージ

  • HTTP エラーステータスコードを使用しない。
  • 理由は、UA は HTTP のエラーステータスコードしか理解しないため。

移行メモ: 元ページの理由の説明は文意が通らない。
仕様の意図は「UA（ブラウザ）は HTTP エラーをそのまま表示してしまい、
SAML レベルのエラーが SP に伝わらない」ということである。
従って HTTP は 200 / 302 で返し、エラーは SAML の <Status> で伝える。

特定のプロトコルまたはプロファイルに対する
単一 or 個別（要求 / 応答）の URL エンドポイントを示す。

割愛（Single Logout Protocol の例なので）

HTML Form Control の Base64 エンコードコンテンツ内で送信するメカニズム。
（「OAuth 2.0 Form Post Response Mode」
みたいな仕様）

HTTP Redirect Binding の HTTP Redirect を Form Post に置き換えたもの。

HTTP Redirect Binding と同じ。

HTTP Redirect Binding の Message Encoding との差分を以下に示す。

• 明記されていないが、先ず、XML 宣言のエンコーディングでエンコード。

• その後、Base64 エンコードのみ行う。

  • DEFLATE 圧縮 — 文字列長は気にしないので、圧縮は不要。
  • URL エンコード — form-urlencoded は自動的に行われる。

• HTML Form Control

  • method 属性 : POST
  • action 属性 : 配信先 HTTP エンドポイント
  • name 属性
    • SAMLRequest（SAML Request の場合）
    • SAMLResponse（SAML Response の場合）

• Submit の方法

  • UA がサポートする任意の方法を利用可能。
  • 通常、Client Side Script などを使用する。

• コチラの例が参考になる。

補足（自動 POST と CSP）: 自動送信のために
<body onload="document.forms[0].submit()"> を使う実装が定番だが、
Content Security Policy（CSP）で unsafe-inline を禁止していると動かない
（セキュリティ関連のHTTPヘッダを参照）。

対策は、インライン ハンドラをやめて外部スクリプト（または nonce 付き）にする。
また <noscript> 用に手動の「Continue」ボタンを必ず用意する。

HTTP Redirect Binding の HTTP Redirect を Form Post に置き換えたもの。

HTTP Redirect Binding と同じ。

基本的に HTTP Redirect Binding と同じだが、以下が異なる。

• 署名は、（SAMLRequest or SAMLResponse）と RelayState で別々に行われる。
  （SAMLRequest or SAMLResponse）メッセージが署名されている場合、

  • Root SAML 要素の Destination XML 属性に、UA に指示した URL を含める。
  • 受信者は、値がメッセージが受信された場所と一致することを確認する。

• 署名が別々になるため、個々の完全性保護は可能だが
  （SAMLRequest or SAMLResponse）と RelayState の組合せの
  完全性保護はできない。

• POST の場合、HTTP の Referer ヘッダや、HTTP ログに公開される可能性がない。

移行メモ: 「署名は…別々に行われる」は正確には
「POST Binding では RelayState は署名対象に含まれない」の意。
Redirect Binding ではクエリ文字列全体（RelayState を含む）に
署名するが、POST Binding では XML メッセージの中にしか
署名がないため、RelayState は保護されない。
これも「RelayState に URL を直接入れてはならない」理由になる。

HTTP Redirect Binding と同じ。

HTTP Redirect Binding と同じ。

同様に割愛（Single Logout Protocol の例なので）

• OAuth の Authorization Code みたいな仕様。
• Code を Token に変換するように、Artifact を SAML Assertion などに変換する。

移行メモ: 元ページの Identification は
...:bindings::HTTP-Artifact（コロンが 2 つ）だったので正した。

HTTP Redirect Binding、HTTP POST Binding と組み合わせて使用するため、
UA を仲介者として使用して通信する必要があるが、
メッセージ本体は、SAML リクエスタがレスポンダに Artifact を提示して直接要求する。

移行メモ（正誤）: 元ページは「SAML レスポンダがリクエスタに
Artifact を使用して直接要求する」となっていたが、逆である。
Artifact を受け取った側（＝ SP、SAML リクエスタ）が、
発行元（IdP、SAML レスポンダ）へ <ArtifactResolve> を送る。

Artifact は以下の Binding を使用して送信されるため、これらに倣ってエンコードされる。

• HTTP Redirect Binding — URL エンコードし、SAMLart というクエリ文字列パラメタに配置
• HTTP POST Binding — SAMLart というパラメタに配置するだけで良い。

RelayState も同様に、上記いずれかの Binding に倣って送信される。

• 短く不透明な文字列

SAML_artifact := B64(TypeCode EndpointIndex RemainingArtifact)
  TypeCode         := Byte1Byte2（SAML 2.0 は 0x0004）
  EndpointIndex    := Byte1Byte2
  RemainingArtifact := SAMLレスポンダのストアとリンクする

• Artifact の発行側は以下を「TypeCode := 0x0004」ストアに保持する。

  • RemainingArtifact := SourceID MessageHandle

    • SourceID := 20 byte の 発行者の識別 URL の SHA-1 ハッシュ
    • MessageHandle := 20 byte の RFC 1750 のランダム文字列

  • Message := <samlp:ArtifactResponse> で返却されるメッセージ。

• RemainingArtifact 中の SourceID と EndpointIndex を使用して、
  <samlp:ArtifactResolve> 送信先を特定することが可能。

移行メモ（正誤）: 元ページは MessageHandle を
「16-20 byte」としていたが、仕様上は厳密に 20 バイト
（SourceID 20 + MessageHandle 20 = RemainingArtifact 40 バイト）である。

なお SourceID は SHA-1 だが、これは識別のためのハッシュであって
署名ではないため、SHA-1 の衝突耐性の問題は直接には影響しない。

• 以下で Artifact（SAMLart）のみを送信し、

  • HTTP Redirect Binding
  • HTTP POST Binding

• メッセージ本体は、下記で SAML 要求 / 応答メッセージ交換を行う。

  • <samlp:ArtifactResolve>
  • <samlp:ArtifactResponse>

HTTP Redirect Binding・HTTP POST Binding と同じ。

• UA を仲介者として使用して通信しない同期通信のため、

  • SAML リクエスタとレスポンダの両方の認証が必要
  • Artifact は、使い捨てのシングルユースセマンティクスを
    強制することが推奨される（失敗時も）。
  • 機密性は、TLS か、追加のメカニズムを導入してもイイ。

• RelayState については、HTTP POST Binding と同じ。

補足（Artifact の利点と欠点）: アサーション本体がブラウザを通らないため、

• アサーションがログや履歴に残らない
• アサーションの署名検証を省略しやすい（バックチャネルが TLS 相互認証のため）

という利点がある。一方で

• SP から IdP への直接通信が必要（FW / プロキシの穴あけが要る）
• IdP が状態を持つ（ステートレスにできない）

という運用上の負担が大きく、
現在は POST Binding が主流である
（SAMLを実装する。を参照）。

• 基本は、HTTP Redirect Binding・HTTP POST Binding と同じ。

• 追加で、<samlp:ArtifactResolve> を理解できる場合、
  <samlp:ArtifactResponse> に以下を含める必要がある。

  urn:oasis:names:tc:SAML:2.0:status:Success
  

• 基本は、HTTP Redirect Binding・HTTP POST Binding と同じ。
• 追加で、<samlp:ArtifactResolve> を処理するインデックス付きエンドポイントも
  記述されるべき。

同様に割愛（Single Logout Protocol の例なので）

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

1 Introduction
1.1 Protocol Binding Concepts
1.2 Notation

2 Guidelines for Specifying Additional Protocol Bindings

3 Protocol Bindings
3.1 General Considerations
3.1.1 Use of RelayState
3.1.2 Security
3.1.2.1 Use of SSL 3.0 or TLS 1
3.1.2.2 Data Origin Authentication
3.1.2.3 Message Integrity
3.1.2.4 Message Confidentiality
3.1.2.5 Security Considerations

3.2 SAML SOAP Binding
3.2.1 Required Information
3.2.2 Protocol-Independent Aspects of the SAML SOAP Binding
3.2.2.1 Basic Operation
3.2.2.2 SOAP Headers
3.2.3 Use of SOAP over HTTP
3.2.3.1 HTTP Headers
3.2.3.2 Caching
3.2.3.3 Error Reporting
3.2.3.4 Metadata Considerations
3.2.3.5 Example SAML Message Exchange Using SOAP over HTTP

3.3 Reverse SOAP (PAOS) Binding
3.3.1 Required Information
3.3.2 Overview
3.3.3 Message Exchange
3.3.3.1 HTTP Request, SAML Request in SOAP Response
3.3.3.2 SAML Response in SOAP Request, HTTP Response
3.3.4 Caching
3.3.5 Security Considerations
3.3.5.1 Error Reporting
3.3.5.2 Metadata Considerations

3.4 HTTP Redirect Binding
3.4.1 Required Information
3.4.2 Overview
3.4.3 RelayState
3.4.4 Message Encoding
3.4.4.1 DEFLATE Encoding
3.4.5 Message Exchange
3.4.5.1 HTTP and Caching Considerations
3.4.5.2 Security Considerations
3.4.6 Error Reporting
3.4.7 Metadata Considerations
3.4.8 Example SAML Message Exchange Using HTTP Redirect

3.5 HTTP POST Binding
3.5.1 Required Information
3.5.2 Overview
3.5.3 RelayState
3.5.4 Message Encoding
3.5.5 Message Exchange
3.5.5.1 HTTP and Caching Considerations
3.5.5.2 Security Considerations
3.5.6 Error Reporting
3.5.7 Metadata Considerations
3.5.8 Example SAML Message Exchange Using HTTP POST

3.6 HTTP Artifact Binding
3.6.1 Required Information
3.6.2 Overview
3.6.3 Message Encoding
3.6.3.1 RelayState
3.6.3.2 URL Encoding
3.6.3.3 Form Encoding
3.6.4 Artifact Format
3.6.4.1 Required Information
3.6.4.2 Format Details
3.6.5 Message Exchange
3.6.5.1 HTTP and Caching Considerations
3.6.5.2 Security Considerations
3.6.6 Error Reporting
3.6.7 Metadata Considerations
3.6.8 Example SAML Message Exchange Using HTTP Artifact

3.7 SAML URI Binding
3.7.1 Required Information
3.7.2 Protocol-Independent Aspects of the SAML URI Binding
3.7.2.1 Basic Operation
3.7.3 Security Considerations
3.7.4 MIME Encapsulation
3.7.5 Use of HTTP URIs

4 References
Appendix A. Registration of MIME media type application/samlassertion+xml
Appendix B. Acknowledgments
Appendix C. Notices

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