SAML Bindings のバックアップ(No.9)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• SAML Bindings へ行く。
  • 1 (2019-04-16 (火) 12:54:47)
  • 2 (2019-04-16 (火) 15:21:08)
  • 3 (2019-04-17 (水) 09:34:29)
  • 4 (2019-04-20 (土) 20:14:11)
  • 5 (2019-04-20 (土) 21:24:31)
  • 6 (2019-04-21 (日) 20:17:22)
  • 7 (2019-04-21 (日) 20:24:02)
  • 8 (2019-05-20 (月) 14:13:45)
  • 9 (2019-05-20 (月) 17:09:34)
  • 10 (2019-05-27 (月) 17:02:56)

---

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

汎用認証サイトに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?を含める必要がある。

Security †

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

Use of SSL 3.0 or TLS 1 †

• クライアントがSSL 3.0 または TLS 1.0 を使用する際、
• サーバはX.509 v 3証明書を使用

Data Origin Authentication †

• メッセージに関連するSAMLリクエスタとSAMLレスポンダの両方の認証はオプション
• ベースとなるProtocolで利用できる認証メカニズムを利用して、データ発信元認証を提供できる。
• 仲介者を通過するBindingでは、SAML自体で認証メカニズム提供して使用する。

Message Integrity †

• SAML要求とSAML応答の両方のメッセージ完全性はOPTIONAL
• ベースとなるProtocolで利用できるメカニズムを利用して、完全性を保証できる。
• 仲介者を通過するBindingでは、メッセージ・インテグリティが推奨される。

Message Confidentiality †

• SAML要求とSAML応答の両方のメッセージ機密性はOPTIONAL
• ベースとなるProtocolで利用できるメカニズムを利用して、機密性を保証できる。
• 仲介者を通過するBindingでは、Protocolのメカニズムは要件を満たさない。

Security Considerations †

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

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

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

• 詳細な議論についてはいを参照
  • 特定のプロトコル処理規則[SAMLCore]
  • SAMLセキュリティ問題文書[SAMLSecure]

HTTP Redirect Binding †

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

• URLパラメタでXMLメッセージを送信するには、
  • 特殊エンコードが必要で
  • 文字列長の制限がある。

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

Required Information †

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>要素がある場合、コレを削除（メッセージ長的に問題）

• DEFLATE圧縮メカニズムでSAMLを圧縮する。

• オクテットをBase64エンコードで文字列化する（改行または他の空白は結果から取り除く）。

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

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

• 署名を追加する。

• 署名アルゴリズム識別子[XMLSig]のURI表現を
  URLエンコードし、クエリ文字列のSigAlg?パラメタとしてURLに追加。
  DSAwithSHA1 - http://www.w3.org/2000/09/xmldsig#dsa-sha1
  RSAwithSHA1 - http://www.w3.org/2000/09/xmldsig#rsa-sha1

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

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

• 上記のクエリ文字列（ASCII）を署名アルゴリズムで署名する。

• オクテットをBase64エンコードで文字列化する（改行または他の空白は結果から取り除く）。

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

• ポイント

• 仕様に明記されていないが、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 に変換する | Visual C# プログラミング
  http://program.station.ez-net.jp/special/handbook/csharp/xml/to-response.asp

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

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

  ヘッダに合わせて、（UTF-8で）エンコーディングする。
  （ココでは、InnerXml?を使用しているが、POST Bindingの場合、これでも検証は可能）。

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

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

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

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

Message Exchange †

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

• ポイントは、<samlp:AuthnRequest?>要素のIsPassive?属性 が
  • true の場合、IdPはユーザとの対話が禁止される
  • false の場合、IdPはユーザとの対話が禁止される

と言う点のみ。

HTTP and Caching Considerations †

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

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

Security Considerations †

• UAの仲介者が存在するため、認証、完全性、機密性について
  トランスポート層を頼ることができないので必要に応じて署名を行う。
  • 署名を介したメッセージレベルの認証と完全性の保護に依存。
  • UAの仲介者に対するメッセージの機密性はサポートしない。

• 機密性はOPTIONALで、必要な場合は、SSL 3.0 または TLS 1.0 を使用する。
• クエリ文字列パラメタは、HTTPの Refererヘッダや、HTTPログに公開される可能性がある。

Error Reporting †

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

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

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

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

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 †

Overview †

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

RelayState? †

HTTP Redirect Bindingと同じ。

Message Encoding †

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

• Base64エンコードのみ。

• DEFLATE圧縮
  文字列長は気にしないので、圧縮は不要。

• URLエンコード
  form-urlencodedは自動的に行われる。

• HTML Form Control

• method属性 : POST
• action属性 : 配信先HTTPエンドポイント

• name属性
  • SAMLRequest（SAML Requestの場合）
  • SAMLResponse（SAML Responseの場合）

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

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

Message Exchange †

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

HTTP and Caching Considerations †

HTTP Redirect Bindingと同じ。

Security Considerations †

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

• 署名は、(SAMLRequest or SAMLResponse) and RelayState?で別々に行われる。
  (SAMLRequest or SAMLResponse)メッセージが署名されている場合、
  • Root SAML要素のDestination XML属性に、UAに指示したURLを含める。
  • 受信者は、値がメッセージが受信された場所と一致することを確認する。

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

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

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 †

Overview †

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

Message Encoding †

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

• HTTP Redirect Binding
• HTTP POST Binding

RelayState? †

RelayState?は以下のBindingを使用して送信されるため、これらに倣って送信される。

• HTTP Redirect Binding
• HTTP POST Binding

URL Encoding †

HTTP Redirect Bindingの場合と同様、
URLエンコードし、SAMLartというクエリ文字列パラメタに配置

Form Encoding †

HTTP POST Bindingの場合と同様、
SAMLartというパラメタに配置すダケで良い。

Artifact Format †

• 短く不透明な文字列

• SAML_artifact := B64(TypeCode? EndpointIndex? RemainingArtifact?)
  • TypeCode? := Byte1Byte2（SAML 2.0は0x0004）
  • EndpointIndex? := Byte1Byte2
  • RemainingArtifact? := SAMLリクエスタのストアとリンクする

Required Information †

Format Details †

• SAMLリクエスタは以下を「TypeCode? := 0x0004」ストアに保持する。

• RemainingArtifact? := SourceID MessageHandle?(PK)
  • SourceID := 20 byte の 発行者の識別URL の SHA-1 ハッシュ
  • MessageHandle? := 16-20 byte の RFC1750のランダム文字列

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

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

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リクエスタとSAMLレスポンダの両方の認証が必要（署名による？）
  • Artifactは、使い捨てのシングルユースセマンティクスの強制することが推奨される（失敗時も）。
  • 機密性は、SSL 3.0 または TLS 1.0か、追加のメカニズムを導入してもイイ。

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

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
3.7.5.1 URI Syntax
3.7.5.2 HTTP and Caching Considerations
3.7.5.3 Security Considerations
3.7.5.4 Error Reporting
3.7.5.5 Metadata Considerations
3.7.5.6 Example SAML Message Exchange Using an HTTP URI

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

---

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

     

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.071 sec.