SAMLトラブルシュート＆チェックリスト
主にWebブラウザーSSOでログインに失敗したときの確認手順です。まず、IdP（認証する側）・SP（サービス側）・通信経路のどこで止まったかを確認し、1つのログイン試行を追います。署名や宛先の検証を無効にして通すのではなく、設定と受信内容の違いを調べます。
時刻と有効期間を照合する
署名が正しくても、受信時点で期限外のAssertionは利用できません。サーバーの時計とログの表示方法を分けて確認します。
時刻を確認する
- IdPとSPの時刻同期を確認します。SAMLの時刻値はUTCで、末尾のZが目印です。OSの表示タイムゾーンを同じにするだけでは時計のずれは直りません。
- ConditionsのNotBeforeは有効期間の開始、NotOnOrAfterは終了です。開始時刻は含み、終了時刻は含みません。IssueInstant（発行時刻）だけを期限として扱いません。
- WebブラウザーSSOのBearer SubjectConfirmationDataではNotOnOrAfterも確認します。この要素にNotBeforeは置けません。Conditionsの時刻条件とは別に扱います。
- 許容する時計ずれはライブラリと運用方針の範囲内で小さく設定します。期限検証を止めたり、原因不明のまま大幅に延長したりしません。
境界の読み方
| Conditionsの例 | 意味（時計ずれの許容なし） |
|---|---|
| NotBefore = 2026-01-01T12:00:00Z | 12:00:00 UTCから有効 |
| NotOnOrAfter = 2026-01-01T12:05:00Z | 12:05:00 UTCちょうどでは期限切れ |
宛先と要求への対応を確認する
EntityIDは相手を識別する値、ACSは認証結果を受け取るURLです。同じものとは限りません。信頼済みの設定・メタデータを基準に照合します。
照合する項目
| 項目 | 確認内容 |
|---|---|
| Audience | Bearer Assertionの対象に、自分のSPのEntityIDが含まれるか |
| Recipient | Bearer SubjectConfirmationDataの値が、応答を受けたACS URLと一致するか |
| Destination | 存在する場合は実際の受信先と一致するか。利用Bindingの必須条件も確認 |
| InResponseTo | SP開始では、ResponseとBearer SubjectConfirmationDataが保存済みAuthnRequest IDに対応するか |
環境とリプレイ対策を確認する
- 本番・検証環境のEntityID、https/http、ホスト、ポート、パスを取り違えていないか確認します。プロキシ越しでは外部公開URLの設定も確認します。
- SPから開始したログインで、要求IDの保存先やセッションが失われていないか調べます。IdP開始の応答を許可する運用は別途扱い、すべての応答の照合を省略しません。
- IdP開始の未要求応答にはInResponseToを付けません。POSTのBearer Assertionは、有効期間内の使用済みIDを追跡して再利用を拒否します。
Bindingと符号化を確認する
要求をRedirect、応答をPOSTで送る構成は可能です。往路と復路を同じ方式にそろえる必要はなく、それぞれの送信先がそのBindingを受け付けることを確認します。
方式ごとの確認
| 方式 | 確認内容 |
|---|---|
| HTTP Redirect | 標準のDEFLATE符号化ではXMLをraw DEFLATE→Base64→URL符号化。gzipやzlibのラッパーを付けない |
| HTTP POST | XMLをBase64化してフォームで送信。Redirect用のDEFLATE展開を適用しない |
| HTTP Artifact | SAMLartと、サーバー間のArtifact解決処理を分けて追う |
符号化と署名を切り分ける
HTTPとSAMLの結果を分けて調べる
HTTP 400・500だけでは原因を特定できません。HTTP 200でも、運ばれたSAML ResponseのStatusが失敗を示すことがあります。
失敗した層を確認する
- 通信・HTTP：送信URL、実際に応答したサーバー、TLSエラー、プロキシやアプリのエラーを確認します。
- SAML：StatusCodeと必要に応じた下位コード、IdP/SPの検証結果を照合します。Successでも署名・期限・宛先等の検証が省略できるわけではありません。
- 署名鍵：Issuerに対応する信頼済みメタデータ・登録鍵、ロールオーバー後の更新漏れ、許可アルゴリズムを確認します。メッセージ内の証明書をそのまま信頼しません。
- 証明書：HTTPS用証明書とSAML署名鍵の情報を区別します。メタデータから鍵を信頼するMetadata IOPでは、X.509証明書の期限だけで鍵を無効と判定する方式ではありません。実装が採用する信頼方式を確認します。証明書・メタデータ運用も参照してください。
必要な情報だけ記録する
最初はエラー分類、発生時刻、試行を結び付けるID、期待した宛先と判定結果を使って調べます。
機密情報を保護する
- Assertion・Cookie・アクセストークン・個人属性を公開ログやオンラインのデコードサービスへ貼り付けません。Base64は暗号化ではありません。
- 詳細な通信内容が必要なら、アクセスを限定した検証環境で扱い、保存範囲と期間を絞ります。署名検証前のXML内容は未検証データとして扱います。
- 変更後は新しいログイン試行で確認し、期限切れ・宛先不一致・再送など、本来拒否する条件まで通るようになっていないかも確かめます。
仕様と関連記事
SAML Core (§1.3.3, §2.5, §3.2.2) / SAML Profiles (§4.1.4–4.1.5) / SAML Bindings (§3.4–3.6) / Metadata Interoperability Profile (§2)