- SP: Service Provider, e.g. Jira, Confluence
- IDPIdP: Identity Provider, e.g. ADFS, Google, Okta, Azure AD, Keycloak, Shibboleth
- SP-initiated logout: User clicks logout in e.g. Jira
- IDPIdP-initiated logout: User clicks logout from the IDP IdP side (dashboard/application menu).
SAML login is decentralized in the sense that there is no global session state that all session participants share&check after authentication has taken place. Service providers (e.g. Jira and Confluence) establish their own local sessions based on an assertion/claim of identify from the identity provider at the time of login, but do not check in with the IdP (e.g. ADFS) after that to see if a session is still valid. As a result, SAML Single Logout is actually a notification protocol: The IdP maintains a record of every SP that has participated in any given user session so that when logout is initiated, the IDP IdP can inform each session participant (possibly with the exception of the initiating SP) by sending them a LogoutRequest. This lets an SP know that it should invalidate the given session. Each SP must then acknowledge with a LogoutResponse, indicating whether session termination was successful or not to the IdP. Depending on whether logout was initiated by the IdP itself or an SP participating in the session, the user is then presented with the result in different ways:
- IdP initiated: The user clicked logout from the IdP dashboard/portal (e.g. ADFS). The IdP notifies each SP (e.g. Jira and Confluence).
- When done: The user will usually land on the logout confirmation screen of the IdP.
- SP initiated: The user clicked logout from the SP (e.g. Jira and Confluence). The initiating SP redirects to the IDP IdP with a LogoutRequest, which takes care of sending additional LogoutRequests to the other SPs participating in the session.
- When done: IdP responds to the initiating SP by sending a LogoutResponse. The user will typically land on the logout confirmation page of the initiating SP, but it's really up to the SP as has has control passed back to itself in this case.
All of these notifications and responses are sent via the user's browser using redirects (back-channel bindings for server-to-server notification exists, but is not widely implemented, and we have no plans to support it currently). So logout is a daisy-chain of redirects from one service provider to the next. It follows that if any of the service providers in the chain (or the IDP IdP itself) for some reason fails to redirect onwards, the chain breaks and the user is stuck at the breaking point with little or no idea how they got there; usually some arbitrary error page of the offending session participant.
This can of course be confusing to the user. To mitigate this, some IDPs IdPs implement the redirect notification chain inside an iframe. The user typically sees a "we're now logging you out, please wait" page while the IDP IdP runs the SP notification chain inside the iframe. If any participant fails and breaks the chain inside the iframe, the IDP IdP still has control of the outer page so the user isn't stuck on a completely arbitrary and potentially confusing error page he/she has no idea how they got to. The exact implementation and behaviour of this varies from IDP IdP to IDPIdP, however. As with all other SSO related tasks, we strongly recommend testing capabilities in a staging environment before going to production. And make sure to educate users on what to expect first.
Our implementation does not currently support cross-device or cross-browser SLO. This is a design trade-off where we don't think the cost and complexity (additional distributed caching/session blacklisting layer would be required) makes up for the benefit to most users, but admins should be aware of the limitation.
These are the identify providers we have tested with SLO so far, along with a setup guide for each and a short summary of capabilities/limitations. You should be able to configure SLO for any other IDP IdP by loosely following these instructions, provided the IdP supports SLO by HTTP-Redirect, however.
SP initiated logout is partially supported: The IdP and initiating SP's sessions are terminated, but other session participants are never notified.
IDPIdP-initiated logout is not supported.