SAML署名の基本

🔏 署名の構造

署名は ds:Signature 要素に入り、Assertion単体またはResponse全体に付与されます。検証にはIdPが渡す公開鍵証明書（X.509）を使います。

基本要素

• 📌 署名対象は Assertion または Response 本体のどちらか（両方の場合もある）
• 📌 署名は ds:Signature に格納され、検証にはX.509証明書を利用
• 📌 署名の範囲（Reference URI）がずれていると検証に失敗する

🛡️ 検証時の注意

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

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

• ✅ サーバーの時刻ズレで NotBefore / NotOnOrAfter の検証が落ちていないか
• ✅ Audience が期待するEntityIDと一致しているか
• ✅ 署名対象が想定の要素（Assertion/Response）になっているか
• ✅ 証明書の有効期限切れ・フォーマット違いがないか

証明書運用のポイント

• 🔁 ローテーション時期を把握し、事前にメタデータを更新する
• 🔁 CRL/OCSPが提供されている場合は失効確認を行う
• 🔁 ピン留めしている公開鍵が変わる場合はデプロイ順序に注意
• 🔁 テスト環境と本番で証明書を取り違えないように分離管理する

🧯 よくあるエラーと対処

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

典型例

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

対処のヒント

• 🧭 エラーログに出るReference URIや証明書の指紋を確認する
• 🧭 時刻同期（NTP）とサーバータイムゾーンを確認する
• 🧭 IdP/ SP双方のメタデータを再インポートして差分を解消する

SubjectConfirmation / Conditions の確認

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

• SubjectConfirmationData の Recipient がACS URLと一致しているか
• NotBefore/NotOnOrAfter が現在時刻の範囲内か
• Conditions > AudienceRestriction が期待するEntityIDと一致しているか