As of version 3.5.0, Kantega SSO supports SAML Single Logout (SLO). SLO allows users to be signed out of the IdP and all apps participating in the session simultaneously, whereas without SLO only the local Atlassian session is affected.
At least in theory. The reality is that the level of support for SLO varies wildly from IdP to IdP, and the protocol itself should be regarded as best-effort regardless of IdP. While it will usually work (within the limitations of the IdP), know that logout can sometimes fail partially or fully, leaving the user only partially logged out with orphaned application sessions. If your main objective is termination of the application- and IdP-session, SAML SLO will do what you need; every IdP with any level of support for SLO should handle this fairly reliably. However: If 100% reliable global logout is critical to your use-case and the occasional broken logout chain or lingering/orphaned SP session is unacceptable, consider introducing an API gateway to your architecture instead (or stick with Crowd SSO). Basically any kind of architecture based around global session state and semi-regular polling or a more robust/bespoke notification/event mechanism.
Finally, educating users is crucial to deploying single logout somewhat successfully, including:
Single Logout is currently not supported for Fisheye/Crucible.
A quick index of terms used throughout this documentation.
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 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:
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 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 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 runs the SP notification chain inside the iframe. If any participant fails and breaks the chain inside the iframe, the 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 to IdP, 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.
Further reading on some of the challenges/difficulties of SAML Single-logout here: https://wiki.shibboleth.net/confluence/display/CONCEPT/SLOIssues
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 by loosely following these instructions, provided the IdP supports SLO by HTTP-Redirect, however.
As ever, feel free to let us know if you would like a guide for a certain IdP currently missing. Also don't hesitate to contact support for questions or other feedback.
ADFS fully supports both IdP- and SP-initiated logout.
See: SLO: AD FS.
Azure AD has limited support for SLO.
While both SP- and IdP-initiated logout are reportedly supported, neither actually works. The result is that only basic SP-initiated logout is supported, which allows logout from AAD and the initiating SP.
See: SLO: Azure AD.
GSuite does not support SAML Single logout as an IdP.
Keycloak fully supports SP-initiated Single logout, but to our knowledge does not support IdP-initiated logout.
See: SLO: Keycloak.
SP initiated logout is partially supported: The IdP and initiating SP's sessions are terminated, but other session participants are never notified.
IdP-initiated logout is not supported.
Okta also has a "quirk" where the user must be logged in to initiate logout, or the user gets a login prompt. SLO then proceeds, causing the user to be immediately logged out again. This creates an annoying user experience when there is more than one session participant, for example Jira and Confluence. Unfortunately, there isn't really anything we can do about it.
To illustrate this with an example where a user is logged into Jira and Confluence through Okta.
If the user now clicks Logout in Confluence:
See: SLO: Okta.