ゆるテックノート

SAMLのバインディング方式とは？

SAMLの設定で「リクエストはRedirect、応答はPOST」と書かれていると、同じログインの途中でなぜ方式が変わるのか迷うことがあります。バインディングは、SAMLメッセージを相手に渡すためのルールです。送信方法と署名の範囲、ログイン後の状態を引き継ぐRelayStateを押さえると、IdPとSPの設定を読み解きやすくなります。

🔗 バインディング方式とは？

SAMLにおける「バインディング方式」とは、SAMLメッセージ（Request/Response）をどのように送受信するかを定義するルールです。主にHTTPを利用して伝達されます。

代表的な方式

  • 📌 HTTP-Redirect：URLのクエリ文字列にメッセージを載せてGETリクエストで送信
  • 📌 HTTP-POST：Base64エンコードされたXMLをフォームのPOSTで送信
  • 📌 HTTP-Artifact：メッセージ本体は後からバックチャネルで取得される方式

🚀 HTTP-Redirect方式

AuthnRequestやLogoutRequestなどの要求をURLで渡す方式です。要求の格納先となるクエリパラメータ名はSAMLRequestで、LogoutRequestはその中に入るXMLメッセージの種類です。長いメッセージは、ブラウザやサーバーが受け付けるURL長の制限にかかることがあります。

特徴と注意点

  • ⚠️ メッセージはURLのクエリ文字列（GET）で送信
  • ⚠️ 標準のDEFLATEエンコーディングはraw DEFLATE → Base64 → URLエンコードの順
  • ⚠️ URL長に制限がある（長いSAMLメッセージには不向き）
  • ⚠️ 署名付きメッセージはURLパラメータにも署名情報が追加される
  • ⚠️ 署名検証には受信したURLエンコード済み値を保持して使う。復号して再エンコードしない

📮 HTTP-POST方式

多くのIdP/SP間でデフォルトとして使われる方式で、大きなメッセージの送信にも対応できます。

特徴と注意点

  • ✅ HTMLのformを使ってPOSTで送信される
  • ✅ Base64エンコードされたSAMLメッセージが hidden フィールドに格納される
  • ✅ 標準HTTP-POSTではXMLをBase64化する。Redirectのraw DEFLATE圧縮をそのまま適用しない
  • ✅ サイズ制限が少なく、署名付きメッセージに適している
  • ✅ JavaScriptはフォーム自動送信用であり必須ではない。手動送信ボタンでも送信できる
  • ✅ JavaScript無効時にも進めるよう送信ボタンを用意する

🧩 HTTP-Artifact方式

Artifact方式では、最初に送るのは識別子のみで、メッセージ本体は別途バックチャネル通信で取得されます。

特徴と実装例

  • 🔍 ブラウザからSPに「アーティファクト」と呼ばれるIDだけが送られる
  • 🔍 SPはArtifactResolveというSOAP通信でIdPから本体を取得
  • 🔍 本体をブラウザに載せないが、取得先の認証・完全性・機密性の保護が必要
  • 🔍 Artifact解決は認証と完全性保護を行う。TLS・メッセージ署名の組合せは適用プロファイルに従う
  • 🔍 一部の高セキュリティ要求の現場で使われる
  • 🔍 IdP/SP双方の対応バインディングと到達可能なバックチャネルを確認する

📊 方式の比較と選び方

以下の表は、各バインディング方式の特徴をまとめたものです。

比較表

方式 送信方法 利点 注意点
HTTP-Redirect GET（URLクエリ） 軽量で実装が簡単。SAMLRequestなどに適している。 URL長制限あり。
署名検証が繊細。
パラメータ順に注意。
HTTP-POST POST（HTMLフォーム） サイズ制限が少なく署名付きメッセージに適している。 手動送信も可能。
WebサーバーのPOSTサイズ制限に注意。
HTTP-Artifact ID → SOAPで本体取得 本体をバックチャネルで取得できる。 実装が複雑で対応IdPが限られる。
SOAPのセットアップが必要。

💡 さらに知っておきたいバインディングの豆知識

実務で迷いがちなポイントを短くまとめています。組み合わせや失敗しやすい箇所を押さえておきましょう。

セキュリティと選定の実務観点

  • 🛡️ Redirectは署名の失敗が起こりやすく、検証が難しい場合がある
  • 🛡️ POSTも署名・宛先・有効期限の検証とTLSが必要
  • 🛡️ Artifactは本体の取得経路を分離できる。方式名だけで安全性は決まらない
  • 🛡️ RequestはRedirect、ResponseはPOSTが一般的な組み合わせ

🛡️ バインディングごとの署名要件

署名の付与方法や検証箇所はバインディングごとに異なります。URLの署名とXMLの署名では、保護するデータの範囲も変わります。

要点

  • HTTP-Redirect: 署名対象はSAMLRequestまたはSAMLResponse、RelayState（ある場合のみ）、SigAlgの規定順。URL上の出現順は任意で、検証時に規定順へ並べる。受信したエンコード済み値を維持する。
  • HTTP-POST: XML内部の署名でAssertionやResponseを保護する。SAMLRequestまたはSAMLResponseフォームフィールドにはBase64化したXMLが入り、RelayStateは別のフィールドになる。
  • Artifact: SOAPで本体を解決する。適用プロファイルに従って相手認証・完全性・機密性を保護する。
  • AuthnRequest署名の要否はIdP/ポリシー次第。要求される場合はSPが署名し、IdPが検証する。

RelayStateで引き継ぐ情報と制限

RelayStateは、SAMLの往復の前後で状態を引き継ぐための任意の値です。ログイン後に戻る画面を識別する用途もありますが、SAMLのXMLメッセージそのものではありません。

80バイト以内の値を安全に扱う

HTTP-RedirectとHTTP-POSTの仕様では、RelayStateの値は80バイト以内です。80文字という意味ではなく、URLエンコード後のクエリ文字列全体の上限でもありません。要求にRelayStateが付いていた場合、応答側は対応するRelayStateに受け取った値をそのまま返します。

場面 仕様上の扱い 実装時のポイント
署名付きRedirect RelayStateがあればURL署名の対象に含む 署名検証では受信したエンコード済み値を保持する。
通常のPOSTとXML署名 RelayStateはSAML XMLの外のフォームフィールド XML署名が有効でも、RelayStateまで保護されたとは限らない。
戻り先や状態の復元 値の完全性保護を推奨 推測しにくい短い識別子をサーバー側の状態に対応させる方法がある。

受信した戻り先を検証する

RelayStateを戻り先として使う実装では、受信したURLへ無条件に転送すると、意図しない外部サイトへの誘導につながります。自分のサービス内のパスや事前に許可した戻り先に絞るなど、値を解釈する側で検証が必要です。署名で改ざんを検出できることと、その戻り先を許可してよいことは別の判断になります。

仕様と関連する解説

OASIS SAML bindings（§3.4.3・3.4.4.1・3.5.3・3.5.4）、OWASP SAML Security Cheat Sheet
ログイン全体の流れはSAMLの基本、検証する署名の種類はSAML署名の基本、接続先の設定はメタデータの運用へ。

< SAMLの規格と構成 SAML署名の基本 >