Implementation details and limitationsKantega 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 IdP. 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 side (for the few 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 blocking layer would be required) makes up for the benefit to most users, but admins should be aware of the limitation. For example: The user mark.miller@example.com is signed into his 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 dashboard on the iPad (IdP-initiated logout), causing the 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
|