Single Logout

## Two different questions in one message A `<LogoutRequest>` has to answer two questions before a recipient can act on it, and they are answered by different children. | child element | what it names | how many | |---|---|---| | `<saml:BaseID>`, `<saml:NameID>` or `<saml:EncryptedID>` | the principal, in a form the recipient recognises | exactly one | | `<samlp:SessionIndex>` | one session the recipient holds for that principal | zero or more | The identifier is a name for a human. The index is a name for an episode. Conflating them is the single most common misreading of this message, and it produces two opposite production bugs: ending sessions that should have survived, and ending none at all. ## Why one principal has several sessions Nothing in federation limits a person to one login. Outside counsel reviewing documents for an e-discovery engagement signs in from a laptop in the morning and from a tablet after lunch. Each sign-in ran its own exchange and produced its own session at the review platform, and the identity provider handed out a distinct session index value for each. When the tablet's session is being ended — the device was handed back, or the user pressed sign out there — the laptop session must survive. Only the index distinguishes them. ## What the recipient does with each field 1. Resolve the identifier to a local principal. If the format is a per-login transient identifier, the recipient must have stored the exact value it received, because a later login produces a different one. 2. Look up the sessions it holds for that principal. 3. If one or more `<samlp:SessionIndex>` children are present, end the sessions those values index and leave the rest alone. 4. If none is present, the specification does not dictate the reading; the only safe interpretation, and the usual one, is *every session you hold for this principal*. 5. Answer with a `<LogoutResponse>` saying what happened. ## Where the value comes from The index is not the participant's invention. The identity provider chose it when it issued the login statement and the participant stored it alongside its own session record; the logout message quotes it back. That has a practical consequence worth stating plainly: **a participant that discarded the value, or never stored it, cannot key on it.** It is then forced to the crude behaviour — end everything for that principal, or end nothing — and neither is what the authority asked for. The index is also opaque: it is a matching token, not something to parse for a timestamp or a user name. ## The naming half is just as fragile The identifier must be one *both parties currently recognise*. Three ways that goes wrong in practice: - The participant keyed its session on an email address it mapped from an attribute, while the authority sends a persistent pseudonymous identifier. Nothing matches, and the participant answers that it found no session. - The identifier is encrypted as `<saml:EncryptedID>` and the participant cannot decrypt it, so it cannot even determine whose session is meant. - A per-login transient identifier was received at login, and the participant stored the mapped local user rather than the identifier itself. In all three the message is well-formed, signed and useless. This is the unglamorous reason so many logout integrations report success and leave sessions running. ## What good handling looks like - Store the session index with the session record at login, indexed for lookup, not in a log line. - Store the identifier exactly as received, including its format, and match on that pair rather than on a derived local user name. - Accept multiple `<samlp:SessionIndex>` children; an authority ending several sessions at once is entitled to list them in one message. - Treat an absent index as a request to end everything for that principal, and say so in the answer. - Never widen the blast radius silently: if you cannot match the index but can match the principal, ending all of that person's sessions is defensible, ending nothing is defensible, and doing either without recording it is not. The interview version of this is short: the identifier says *who*, the index says *which login*, and a logout that carries only the first is a logout that either does too much or does nothing.