SAMLシングルログアウト（SLO）

🔁 SLOの基本フロー

IdPまたはSPのどちらかがLogoutRequestを送るところから始まります。

典型的な流れ

• ➡️ ユーザーがSPまたはIdPで「ログアウト」を実行
• ➡️ SAML LogoutRequest が相手に送られる
• ➡️ 相手が LogoutResponse を返却し、セッション終了を確認
• ➡️ 複数SPがある場合、連鎖的にLogoutRequestが送られることもある

🧭 片側発火/両側発火の設計

どちらがSLOのトリガーを持つかを決め、ユーザー体験を揃えます。

設計のポイント

• ✅ IdP起点：一括ログアウトしやすいが、SP連携設定が揃っている必要がある
• ✅ SP起点：特定サービスからのログアウト時に他サービスも閉じたい場合に有効
• ✅ どちらで発火しても整合性が取れるよう、メッセージ順序と再送制御を決める

🛡️ セッション管理とブラウザ対応

Cookie削除だけでは足りないケースがあります。IdP/SP双方でセッション終了を明示します。

運用のヒント

• 🔍 IdP側セッションとSP側セッションを両方終了させる
• 🔍 ブラウザがサードパーティCookieをブロックする場合、埋め込みiframeによるSLOが失敗しやすい
• 🔍 失敗時にユーザーへ「完全ログアウトできなかった」旨を通知するUIを用意する

🧯 ログアウト失敗時の扱い

SLOは複数システムが絡むため、失敗時のリカバリ手順を決めておくと安心です。途中のSPがエラーを返すとフローが停止し、他のSPはログイン継続になることがあります（IdP/イニシエーター側でスキップ制御できない実装が多い）。

よくある失敗と対策

• ⚠️ 一部SPへのLogoutRequestが届かない：リトライ/タイムアウト設計を入れる
• ⚠️ レスポンス不一致：IdP/SPでメッセージ署名要否が異なると失敗することがある
• ⚠️ ユーザーのブラウザが閉じられている：次回アクセス時に再ログインを促す

SLOプロファイル上の期待値

SAML Single Logout Profileでは、部分失敗の扱いは実装依存になりがちです。部分成功時の通知や再試行手順を運用で決めておくとよいでしょう。

• 一部成功/一部失敗のステータスをユーザーに通知する設計を検討する
• 失敗SPのみリトライするか、手動ログアウト案内を出す
• IdPの実装によっては部分失敗で処理停止するため、事前に挙動をテストする