Why does SAML 2.0 define a Single Logout profile instead of leaving each service provider to drop its own session?

## Three kinds of session, not one When a user signs in through SAML 2.0 Web Browser SSO, the login produces more state than most people picture. The identity provider records that this human authenticated and keeps a session of its own with the browser — that session is exactly what makes the *next* service provider's login silent. Each service provider that consumed an assertion then creates a session of its own, normally a cookie plus a server-side record. Nothing links those sessions at runtime except the identity provider's memory of which parties it issued assertions to during this login. So the word *logout* is ambiguous until you say whose session you mean: - the identity provider's session, held in its role as **session authority**; - each service provider's own application session, held as a **session participant**; - the browser cookie that actually carries each of those. ## Session authority and session participant The profile names roles, not products. The **session authority** is the party that issued the authentication statements and therefore knows the list of parties that hold sessions off this login. The **session participant** is any party holding such a session. A party can be both: an identity provider that authenticated its users against another identity provider upstream is a participant in that upstream session while being the authority for its own. ## What the profile actually does 1. Someone initiates. A participant sends a `<LogoutRequest>` to the authority, or the authority starts the exchange itself — an agreed global timeout has expired, a credential is suspected compromised, or an administrator is ending an engagement. 2. The authority ends its own session and issues a `<LogoutRequest>` to each remaining participant, naming the principal and, where it has one, the `SessionIndex` that identifies the session at that participant. 3. Each participant ends what it can and answers with a `<LogoutResponse>`. 4. The authority answers the initiator with its own `<LogoutResponse>`: `urn:oasis:names:tc:SAML:2.0:status:Success`, or `Success` qualified by a second-level `urn:oasis:names:tc:SAML:2.0:status:PartialLogout` when not every participant confirmed. ## Why clearing the local session is not enough | sign-out action | what it ends | what is still live | |---|---|---| | A service provider clears its own cookie and session record | that one application session | the authority's session and every other participant's | | The user clears the identity provider's cookie only | the authority's session | every participant's session, until each expires on its own | | A `<LogoutRequest>` propagated to every participant | each session the authority can reach | anything held by a participant that never confirmed | The middle row is the one that surprises people. Ending the authority's session stops *new* silent logins but does not reach back into sessions that already exist; an application with an eight-hour session keeps the user for the rest of the working day. ## What the profile does not promise - It is **not transactional**. There is no rollback and no obligation on the authority to retry a participant that never answered. - It does **not** guarantee completeness, which is precisely why a distinct `PartialLogout` second-level status code exists. - It cannot reach a participant the authority does not know about — a session created outside this login is invisible to it. - It depends on a value the participant can act on: a participant that was never given a `SessionIndex` has to decide for itself which of the principal's sessions to end. - A `<LogoutRequest>` or `<LogoutResponse>` carried over the HTTP-POST or HTTP-Redirect binding **must be signed**, because it crosses the user agent, which can alter it. ## A worked setting An e-discovery review platform gives outside counsel, working from the client's own network, access to three federated applications: the review tool, the document store and the transcript viewer. When the engagement closes, the contract says reviewer access ends at that moment — not at the end of the longest session timeout. Without the Single Logout profile, revoking the account at the authority stops the next login and leaves three live sessions behind it. With the profile, the authority walks its participant list and each application is told, by name, which principal and which session to end. What the platform then owes its client is an honest report of which of the three confirmed, and that is what the status code in the final `<LogoutResponse>` is for.