SaaS やアプリを SP（Service Provider） として SAML SSO に対応させる際の実装の勘所をまとめます。OIDC に比べ XML 署名の扱いが難所です。

メタデータの交換

SAML は IdP と SP が互いのメタデータ XML を交換することで信頼関係を結びます。

  • SP メタデータ：EntityID、ACS（Assertion Consumer Service）URL、署名証明書
  • IdP メタデータ：EntityID、SSO URL、IdP の署名証明書

多くの IdP は「メタデータ URL」を提供するので、SP 側はそれを取り込むのが確実です。

ログインの流れ（SP-initiated）

  1. ユーザーが SP にアクセス → SP が AuthnRequest を生成し IdP へリダイレクト
  2. IdP が認証（＋MFA）
  3. IdP が SAML Response（アサーション） を SP の ACS に POST
  4. SP がアサーションを検証してログイン確立

アサーション検証で必須のチェック

ここを省くと認証を迂回されます。

  • 署名検証：IdP の証明書でアサーション（と Response）の XML 署名を検証
  • Issuer：信頼する IdP の EntityID か
  • Audience（Recipient）：自分の EntityID/ACS URL 宛か
  • 条件（Conditions）：NotBefore / NotOnOrAfter の時刻が有効か
  • InResponseTo：自分が送った AuthnRequest の ID と一致するか（リプレイ防止）
  • 再利用防止：同じアサーション ID を使い回されていないか

XML 署名の落とし穴

SAML は XML Signature Wrapping（XSW） という署名迂回攻撃が知られています。署名対象の要素を取り違えると、攻撃者が細工したアサーションを通してしまいます。

  • 対策：自前実装を避け、実績ある SAML ライブラリを使う。検証対象の要素（署名された Assertion 本体）を厳密に特定する。

OIDC との比較

新規開発で選べるなら、XML 署名の複雑さがない OpenID Connect のほうが実装は容易です。既存 SaaS 連携で SAML 必須のケースに SP 実装が必要になります（SAML vs OIDC）。

まとめ

SAML SP 実装の肝は「メタデータで信頼を結ぶ」「アサーションの署名・宛先・時刻・InResponseTo を必ず検証」「自前の XML 署名検証を避ける」。トークン検証一般の注意は JWT検証の落とし穴 も参考になります。