SAML署名の基本

🔏 署名の構造

署名は ds:Signature 要素に入り、Assertion単体またはResponse全体に付与されます。検証には事前に信頼を確立したIdPの公開鍵を使います。受信XMLに含まれる証明書だけを信頼してはいけません。

基本要素

• 📌 署名対象は Assertion または Response 本体のどちらか（両方の場合もある）
• 📌 署名は ds:Signature に格納され、検証にはX.509証明書を利用
• 📌 検証に成功した署名対象の要素を、そのまま認証判断に使う。別の未署名Assertionを読み取ると署名ラッピング攻撃につながる

🛡️ 検証時の注意

署名が正しいかだけでなく、レスポンスの条件や証明書の状態も合わせて確認します。

よくあるチェックポイント

• ✅ サーバーの時刻ズレで NotBefore / NotOnOrAfter の検証が落ちていないか
• ✅ Audience が期待するEntityIDと一致しているか
• ✅ 署名対象が想定の要素（Assertion/Response）になっているか
• ✅ 登録鍵・証明書形式と、採用する信頼モデルに応じた期限ポリシーを確認する

証明書運用のポイント

• 🔁 ローテーション時期を把握し、事前にメタデータを更新する
• 🔁 鍵の失効・期限の扱いは証明書の信頼モデルに従う
• 🔁 ピン留めしている公開鍵が変わる場合はデプロイ順序に注意
• 🔁 テスト環境と本番で証明書を取り違えないように分離管理する

🧯 よくあるエラーと対処

署名周りで失敗する典型パターンと、切り分けのヒントを押さえておくと復旧が早くなります。

典型例

• ⚠️ 署名検証エラー：証明書不一致、署名範囲ミス、改ざんの可能性
• ⚠️ XML解析エラー：Deflate展開やBase64デコードに失敗
• ⚠️ 条件不一致：時刻ズレやAudience不一致で無効になる

対処のヒント

• 🧭 エラーログに出るReference URIや証明書の指紋を確認する
• 🧭 時刻同期とUTC日時の解釈を確認する。表示タイムゾーンの違いだけで時刻ずれとは判断しない
• 🧭 信頼できる配布元のメタデータと差分を照合し、変更内容を確認して更新する

SubjectConfirmation / Conditions の確認

AssertionのSubjectConfirmation（特にBearer）やConditionsは検証必須です。Recipient/NotOnOrAfter/Audienceが合わないと正当な受信者とみなされません。

• SubjectConfirmationData の Recipient がACS URLと一致しているか
• ConditionsのNotBeforeとNotOnOrAfter、BearerのSubjectConfirmationDataのNotOnOrAfterを検証する。SP起点ではInResponseToを未使用の要求IDと照合し、Assertion IDの再利用も拒否する
• Conditions > AudienceRestriction が期待するEntityIDと一致しているか

仕様と関連する解説

OASIS SAML profiles / OASIS Metadata Interoperability Profile / OWASP SAML Security Cheat Sheet
関連するSAML解説