skip to content

In SAML Single Logout, why can the SOAP back channel fail to end a session a front-channel chain would end?

level: seniorimportance: should knowfreq 34%

answer

  1. server to server never touches the browser
  2. some session state is only a cookie
  3. the chain needs the user agent present
  4. one stalled participant holds up the rest
  5. confidential and synchronous, but unreachable

basics

~20 s

A SOAP logout is a server-to-server call and can only delete state the participant holds server-side. A participant whose session exists solely as a cookie in the user agent has nothing to delete, so only a front-channel hop through the browser can end it.

solid answer

~40 s

The SOAP binding gives the session authority a direct, synchronous, confidential call to each participant: no browser, no user cooperation, an immediate `<LogoutResponse>`. Its limit is structural — it never touches the user agent. If a participant's session state lives only as a cookie in the browser, the server-to-server call has nothing to act on and the session survives a perfectly successful exchange. That is the specification's own reason for preferring a front-channel binding for such participants: the authority sends the user agent to each one in turn with a `<LogoutRequest>`, and each clears its own cookie before handing the browser back. The price is that the chain is sequential, visible, interruptible — the user closes the tab, a participant stalls — and every message must be signed because it crosses the browser.

code

pseudocode · 21 lines
pseudocode
function propagate_logout(session, initiator):
    for each participant in session.participants:
        mark participant unconfirmed

    for each participant in session.participants:
        if participant.channel is SOAP:
            send LogoutRequest directly to participant
            wait for LogoutResponse
            if status is Success:
                mark participant confirmed
        else:
            send the user agent to participant with the LogoutRequest
            wait for the user agent to return with a LogoutResponse
            if nothing returns within the window:
                stop                      // the browser is gone
            if status is Success:
                mark participant confirmed

    if every participant is confirmed:
        return Success
    return Success with second-level PartialLogout

go deeper

for a junior

Recall that a logout can travel two ways: through the user's browser, or directly between servers, and that the two reach different things.

for a middle

Explain why a server-to-server call cannot end a session held as a browser cookie, and what the browser-borne chain gives up in exchange.

for a senior

Diagnose the real report — logout works everywhere but one application — by asking where that participant keeps its session and how the authority reaches it.

for a principal

The call to own is which participants you are willing to leave on the front channel at all, given that an abandoned chain is abandoned in order.

## Two ways to reach a session participant The Single Logout profile does not mandate one transport. The session authority can reach a participant two ways, and the choice is not a matter of taste. | | front channel (Redirect, POST, Artifact) | back channel (SOAP) | |---|---|---| | who carries the message | the user agent, as a sequence of navigations | the authority's own server | | can end session state held only in a cookie | yes | no | | survives the user closing the tab | no | yes | | visible and alterable in transit | yes — hence the signing requirement | no, it is a direct call | | effect of one slow participant | the whole chain waits behind it | only that one call waits | | confirmation | arrives when the browser comes back | arrives synchronously in the same exchange | ## The structural limit of a server-to-server call A SOAP `<LogoutRequest>` travels from the authority's server to the participant's endpoint and never goes near the browser. The participant looks up the principal and the session index, ends what it finds, and answers. Everything about that is better than the front channel — it is confidential, it is synchronous, it does not depend on a human — except for one thing it structurally cannot do. **If the participant's session state exists only as a cookie in the user agent, there is nothing on the participant's server to end.** A stateless application that trusts a signed cookie and keeps no server-side record is the pure case, and it is common. The authority calls, the participant looks, finds nothing to delete, and answers successfully. The exchange is clean and the user is still signed in. This is the reason the profile prefers a front-channel binding for participants of that shape: only a navigation through the browser can carry the instruction to the place the session actually lives. ## What the front channel costs The authority redirects or posts the user agent to the first participant with a `<LogoutRequest>`, that participant clears the session and sends the browser onward with a `<LogoutResponse>`, and so on down the list before the browser finally returns to the initiator. The cost is a list of failure modes that only appear in production: - **The user closes the tab.** The chain stops where it stands. Participants already visited are done, the rest were never asked, and the authority may never produce a final response at all. - **A participant stalls.** Because the chain is sequential, a participant that is slow or down holds up every participant behind it until the authority times it out and moves on. - **A participant has no session index to match.** It was never given one, or never stored one, so it either ends everything for that principal or nothing. - **A participant only accepts the back channel** while holding its session in a cookie — the unreachable combination, and the one worth naming in an interview. - **The authority initiates for its own reasons.** An agreed global timeout expires or a credential is suspected compromised, and participants receive a logout in the middle of a user's work with no interaction to explain it. Because front-channel messages cross the user agent, which can read and modify them, a `<LogoutRequest>` or `<LogoutResponse>` carried over HTTP-POST or HTTP-Redirect must be signed. That is a rule of this profile, not an optional hardening. ## How this is actually decided In practice an estate is mixed, and the authority chooses per participant from what that party is prepared to accept. A sensible posture: 1. Use the back channel for participants with real server-side session state — it completes without the user and it reports honestly. 2. Use the front channel for any participant whose session is a browser cookie, and accept the chain. 3. Order the chain so the participants that matter most are visited first, because a chain that is abandoned halfway is abandoned in order. 4. Time out a stalled participant rather than letting it hold the user's browser. 5. Expect the incomplete outcome and report it, rather than designing as though the chain always finishes. ## The diagnosis to recognise The report is always the same shape: *logout works, except for that one application*. The instinct is to look for a broken signature or a wrong endpoint. The question to ask first is where that application keeps its session, and how the authority reaches it — because a back-channel call to a cookie-only participant produces a successful exchange, a successful status code, and a user who is still signed in. Nothing in the logs looks wrong, and that is exactly why it survives in estates for years.

  • What most often breaks a front-channel logout chain in production?
    The user leaves. The chain is a sequence of navigations, so closing the tab or clicking away mid-way stops it where it stands: the participants already visited are done, the rest were never asked, and the initiator may get no final response at all. A participant that stalls does the same thing more slowly, by holding the browser until the authority times it out.
  • Why must a logout message carried over HTTP-Redirect or HTTP-POST be signed?
    Both bindings route the message through the user agent, so whoever controls the browser can read and alter it before the next party sees it. The profile therefore requires the `<LogoutRequest>` and `<LogoutResponse>` carried that way to be signed. How the signature is constructed and verified is a separate subject; the point here is that an unsigned front-channel logout message is not conformant.
  • Can one participant be reachable both ways?
    Yes. A party may make more than one logout endpoint available, with different bindings, and the authority picks per exchange. That is the pragmatic arrangement for an application with server-side session state that also keeps a browser cookie: the back channel ends the record, a front-channel hop clears what the browser holds.

A building's front desk can telephone each tenant floor to cancel a visitor's access, and every floor that keeps a list will strike the name off. The floor that simply trusts the pass in the visitor's pocket cannot be reached by telephone at all — someone has to walk the visitor past that floor's reader on the way out.

saying these in an interview costs you the question

  • Thinks the back channel is strictly better because it is confidential.
  • Assumes the browser is unnecessary once the authority has its participant list.
  • Believes a server-to-server logout can clear a cookie in the user agent.
  • Expects the chain to continue after the user closes the tab.
  • Assumes an unanswering participant costs the chain nothing but a moment.