MS_SAMLBindings

SAML Bindings

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

概要

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

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

Introduction

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

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

は、SAML Bindings と呼ばれる。

Protocol Binding Concepts

特定の通信プロトコル <FOO> にマッピングした
SAML Bindings は、SAML <FOO> Binding と呼ばれる。
この仕様の目的は、
- SAML 準拠ソフトウェアが確実に相互運用できるように、
  Binding を十分に詳細に指定すること。
- 特に指定のない限り、Binding は、以下から派生したメッセージとその送信をサポートする。
  - samlp:RequestAbstractType
  - samlp:StatusResponseType

Notation

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

Specifying Additional Protocol Bindings

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

以下、詳細

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

General Considerations

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

Use of RelayState

幾つかの 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 は入りきらないことが多い。

Security

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

項目	内容
Use of SSL 3.0 or TLS 1	クライアントが SSL 3.0 または TLS 1.0 を使用する際、サーバは X.509 v3 証明書を使用
Data Origin Authentication	メッセージに関連する SAML リクエスタとレスポンダの両方の認証は OPTIONAL。仲介者を通過する Binding では、SAML 自体で認証メカニズムを提供して使用する。
Message Integrity	SAML 要求と応答の両方のメッセージ完全性は OPTIONAL。仲介者を通過する Binding では、メッセージの完全性保護が推奨される。
Message Confidentiality	SAML 要求と応答の両方のメッセージ機密性は OPTIONAL。仲介者を通過する Binding では、Protocol のメカニズムは要件を満たさない。

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

Security Considerations

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

以下のコンテキスト上での、プロトコル交換 / 展開環境
メカニズムの組合せ（認証 / メッセージの完全性 / メッセージの機密性）
詳細な議論については以下を参照
- 特定のプロトコル処理規則 [SAMLCore]（SAML Core）
- SAML セキュリティ問題文書 [SAMLSecure]

HTTP Redirect Binding

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

URL パラメタで XML メッセージを送信するには、
- 特殊エンコードが必要で
- 文字列長の制限がある。
HTTP POST Binding または HTTP Artifact Binding
- 2 つの異なる Binding を組み合わせて要求 / 応答メッセージを送信可能。
- HTTP Redirect Binding より大規模で複雑なメッセージを送信可能。

Required Information

#	項目	説明
1	Identification	`urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`
2	Contact information	security-services-comment@lists.oasis-open.org
3	Updates	None.

Overview

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

RelayState

RelayState が含まれてもよい。

値は長さが 80 バイトを超えてはならない。
他の保護から独立してエンティティによって完全性保護されるべき。
値は長さ制限から、署名は現実的でないので、
チェックサム・擬似乱数を使用して改ざんを確認。
SAML リクエスタが SAML 要求メッセージに RelayState データを
- 添付する場合、SAML レスポンダは、
  - RelayState をサポートする Binding を選択して応答する必要がある。
  - 受け取ったデータを、そのままレスポンスの中の対応する
    RelayState パラメタに入れる。
- 添付しない場合、SAML レスポンダは、
  Profile または事前の合意の使用に基づいて RelayState データを含めることができる。

Message Encoding

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

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

DEFLATE Encoding

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

シリアル化手順

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

署名を追加する。

署名アルゴリズム識別子 [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 と同じ問題である）。

Message Exchange

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 and Caching Considerations

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

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

Security Considerations

UA の仲介者が存在するため、認証、完全性、機密性について
トランスポート層を頼ることができないので必要に応じて署名を行う。
- 署名を介したメッセージレベルの認証と完全性の保護に依存。
- UA の仲介者に対するメッセージの機密性はサポートしない。
機密性は OPTIONAL で、必要な場合は、TLS を使用する。
クエリ文字列パラメタは、HTTP の Referer ヘッダや、HTTP ログに
公開される可能性がある。

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

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

Error Reporting

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> で伝える。

Metadata Considerations

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

Example SAML Message Exchange Using HTTP Redirect

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

HTTP POST Binding

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

Required Information

#	項目	説明
1	Identification	`urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`
2	Contact information	security-services-comment@lists.oasis-open.org
3	Updates	SAML V1.1 の Browser/POST profile を効果的に置き換える。

Overview

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

RelayState

HTTP Redirect Binding と同じ。

Message Encoding

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」ボタンを必ず用意する。

Message Exchange

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

HTTP and Caching Considerations

HTTP Redirect Binding と同じ。

Security Considerations

基本的に 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 を直接入れてはならない」理由になる。

Error Reporting

HTTP Redirect Binding と同じ。

Metadata Considerations

HTTP Redirect Binding と同じ。

Example SAML Message Exchange Using HTTP POST

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

HTTP Artifact Binding

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

Required Information

#	項目	説明
1	Identification	`urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact`
2	Contact information	security-services-comment@lists.oasis-open.org
3	Updates	SAML V1.1 の Browser/Artifact profile を効果的に置き換える。

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

Overview

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

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

Message Encoding

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

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

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

Artifact Format

短く不透明な文字列

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

Required Information

#	項目	説明
1	Identification	`urn:oasis:names:tc:SAML:2.0:artifact-04`
2	Contact information	security-services-comment@lists.oasis-open.org
3	Updates	None.

Format Details

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 の衝突耐性の問題は直接には影響しない。

Message Exchange

以下で Artifact（SAMLart）のみを送信し、
- HTTP Redirect Binding
- HTTP POST Binding
メッセージ本体は、下記で SAML 要求 / 応答メッセージ交換を行う。
- <samlp:ArtifactResolve>
- <samlp:ArtifactResponse>

HTTP and Caching Considerations

HTTP Redirect Binding・HTTP POST Binding と同じ。

Security Considerations

UA を仲介者として使用して通信しない同期通信のため、
- SAML リクエスタとレスポンダの両方の認証が必要
- Artifact は、使い捨てのシングルユースセマンティクスを
  強制することが推奨される（失敗時も）。
- 機密性は、TLS か、追加のメカニズムを導入してもイイ。
RelayState については、HTTP POST Binding と同じ。

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

アサーションがログや履歴に残らない

アサーションの署名検証を省略しやすい（バックチャネルが TLS 相互認証のため）

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

SP から IdP への直接通信が必要（FW / プロキシの穴あけが要る）

IdP が状態を持つ（ステートレスにできない）

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

Error Reporting

基本は、HTTP Redirect Binding・HTTP POST Binding と同じ。
追加で、<samlp:ArtifactResolve> を理解できる場合、
<samlp:ArtifactResponse> に以下を含める必要がある。
```
urn:oasis:names:tc:SAML:2.0:status:Success
```

Metadata Considerations

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

Example SAML Message Exchange Using HTTP Artifact

同様に割愛（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

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

NetDevInfraWiki

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

Open 棟梁 Wiki

（未着手）

TOP

開発基盤部会 Wiki

TOP
サービス
- 企画
- 価値
- 技術
- 見積
- …ほか（サービス）
DX
BI / AI
Linux
- Linuxのディストリビューション
- Linuxを触ってみる。
- Docker
- CaaS (Open PaaS)
- …ほか（Linux）
Java
- Javaを書いてみる。
- Java有償化について調べてみた。
OSS
- ライセンス
- 開発方法論
- ビジネスモデル
- 導入事例
- …ほか（OSS）
開発環境
その他

移行管理: DONE ／ TODO

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

MS_SAMLBindings

SAML Bindings

概要

Introduction

Protocol Binding Concepts

Notation

Specifying Additional Protocol Bindings

以下、詳細

General Considerations

Use of RelayState

Security

Security Considerations

HTTP Redirect Binding

Required Information

Overview

RelayState

Message Encoding

DEFLATE Encoding

Message Exchange

HTTP and Caching Considerations

Security Considerations

Error Reporting

Metadata Considerations

Example SAML Message Exchange Using HTTP Redirect

HTTP POST Binding

Required Information

Overview

RelayState

Message Encoding

Message Exchange

HTTP and Caching Considerations

Security Considerations

Error Reporting

Metadata Considerations

Example SAML Message Exchange Using HTTP POST

HTTP Artifact Binding

Required Information

Overview

Message Encoding

Artifact Format

Required Information

Format Details

Message Exchange

HTTP and Caching Considerations

Security Considerations

Error Reporting

Metadata Considerations

Example SAML Message Exchange Using HTTP Artifact

参考

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!