マイクロソフト系技術情報 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

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

#項目説明
1Identificationurn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
2Contact informationsecurity-services-comment@lists.oasis-open.org
3UpdatesNone.

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に追加。
  • 署名を追加する。
  • 次のいずれかの方法でクエリ文字列を構築する。
    SAMLRequest=value&RelayState=value&SigAlg=value
    SAMLResponse=value&RelayState=value&SigAlg=value
  • 上記のクエリ文字列をASCIIエンコードし、署名アルゴリズムで署名する。
  • オクテットをBase64エンコードで文字列化する(改行または他の空白は結果から取り除く)。
  • Base64をURLエンコードし、クエリ文字列のSignatureパラメタとしてURLに追加。
  • ポイント
  • 仕様に明記されていないが、XML → UTF-8エンコーディング → DEFLATE圧縮とするらしい。
  • 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

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

Overview

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

RelayState?

HTTP Redirect Bindingと同じ。

Message Encoding

HTTP Redirect BindingMessage 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などを使用する。

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

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

Required Information

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

Overview

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

Message Encoding

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

RelayState?

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

URL Encoding

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

Form Encoding

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

Artifact Format

  • 短く不透明な文字列

Required Information

#項目説明
1Identificationurn:oasis:names:tc:SAML:2.0:artifact-04
2Contact informationsecurity-services-comment@lists.oasis-open.org
3UpdatesNone.

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

  • メッセージ本体は、下記でSAML要求 / 応答メッセージ交換を行う。
    • <samlp:ArtifactResolve?>
    • <samlp:ArtifactResponse?>

HTTP and Caching Considerations

HTTP Redirect BindingHTTP POST Bindingと同じ。

Security Considerations

  • UAを仲介者として使用して通信しない同期通信のため、
    • SAMLリクエスタとSAMLレスポンダの両方の認証が必要(署名による?)
    • Artifactは、使い捨てのシングルユースセマンティクスの強制することが推奨される(失敗時も)。
    • 機密性は、SSL 3.0 または TLS 1.0か、追加のメカニズムを導入してもイイ。

Error Reporting

  • 追加で、<samlp:ArtifactResolve?>を理解できる場合、
    <samlp:ArtifactResponse?>に以下を含める必要がある。
    urn:oasis:names:tc:SAML:2.0:status:Success

Metadata Considerations

  • 追加で、<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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-05-28 (火) 11:10:41 (88d)