Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • 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.


titleImplementation details and limitations
  • Kantega SSO initiates SLO using the HTTP-Redirect profile only, for now. Incoming messages (LogoutResponse/LogoutRequests) handle both HTTP-Redirect and HTTP-Post binding, however, and the appropriate binding will be used to respond. 
  • All communication is done via the browser: There are no server-to-server calls between any service provider or the IDPIdP. The only network requirement is that the user's browser has access to the application.
  • Single logout is only initiated when the user explicitly clicks logout in the Atlassian app or on the IDP IdP side (for the few IDPs IdPs that support this). As an administrator, consider how often users actually use the logout button actively (as opposed to just allowing their session to time out) before taking on the added complexity of introducing SLO.

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.

For example:

  • The user is signed into his IDP IdP on both his iPad and Windows PC. 
  • Mark is currently logged into Jira on his Windows PC.
  • Mark is also using an in-house SAML capable app on the iPad.
  • Mark then clicks Logout from his IDP IdP dashboard on the iPad (IDPIdP-initiated logout), causing the IDP IdP to send a LogoutRequest to all service providers currently participating in any of Mark's sessions. 
  • In this case, the logout chain is performed by the iPad. We are unable to sign Mark out of Jira as the iPad does not have Mark's session cookie: Mark can continue to use his PC Jira session


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.