SAMLシングルログアウト（SLO）
SLOは「どちらが起点になるか」「全サービスをどう閉じるか」を事前に設計しておくと安全です。ここではフローと運用上の注意を整理します。
🔁 SLOの基本フロー
IdPまたはSPのどちらかがLogoutRequestを送るところから始まります。
典型的な流れ
- ➡️ ユーザーがSPまたはIdPで「ログアウト」を実行
- ➡️ SAML LogoutRequest が相手に送られる
- ➡️ LogoutResponseの署名等とStatusを検証し、完了・部分失敗を判定する
- ➡️ 複数SPがある場合、連鎖的にLogoutRequestが送られることもある
🧭 片側発火/両側発火の設計
どちらがSLOのトリガーを持つかを決め、ユーザー体験を揃えます。
設計のポイント
- ✅ IdP起点：一括ログアウトしやすいが、SP連携設定が揃っている必要がある
- ✅ SP起点：特定サービスからのログアウト時に他サービスも閉じたい場合に有効
- ✅ どちらで発火しても整合性が取れるよう、メッセージ順序と再送制御を決める
🛡️ セッション管理とブラウザ対応
Cookie削除だけではサーバー側セッションは失効しません。検証済みLogoutRequestのNameIDとSessionIndex（指定時）を対象セッションに対応付けます。署名等による送信元・完全性確認と、応答のInResponseTo照合も必要です。
運用のヒント
- 🔍 IdP側セッションとSP側セッションを両方終了させる
- 🔍 ブラウザがサードパーティCookieをブロックする場合、埋め込みiframeによるSLOが失敗しやすい
- 🔍 失敗時にユーザーへ「完全ログアウトできなかった」旨を通知するUIを用意する
🧯 ログアウト失敗時の扱い
SLOの途中失敗では他のSPのセッションが残り得ます。どこまで終了したかを確認し、全サービスからログアウトしたと誤表示しないようにします。
よくある失敗と対策
- ⚠️ 一部SPへのLogoutRequestが届かない：リトライ/タイムアウト設計を入れる
- ⚠️ レスポンス不一致：IdP/SPでメッセージ署名要否が異なると失敗することがある
- ⚠️ ブラウザ終了はサーバー側セッションの失効を保証しない。残存セッションを確認し、必要に応じて個別ログアウトを案内する
SLOプロファイル上の期待値
SAML Coreは、全参加者へのログアウトが確認できない場合の第二階層ステータスPartialLogoutを定義しています。受信側はStatusを確認し、再試行や個別ログアウト案内を用意します。
- 一部成功/一部失敗のステータスをユーザーに通知する設計を検討する
- 失敗SPのみリトライするか、手動ログアウト案内を出す
- IdPの実装によっては部分失敗で処理停止するため、事前に挙動をテストする