SSO not signing out

Question

Hi,

We just updated from stash to BitBucket. SSO is working. If I login to say confluence and then go to the BitBucket URL I am logged in. If I logout of of BitBucket it will automatically log me out of Confluence. The issue is if I login to BitBucket, go to Confluence or Jira and then select the logout option from Jira or Confluence if I go back to BitBucket I will still be logged in. The only way to be logged out of BitBucket is to go to my BitBucket URL and click logout. What's interesting is if I log out of BitBucket I then can't get to Jira or Confluence without logging back in.

EDIT: In crowd if I have consistent client IP address checked then the issue goes away. If I have it unchecked the issue comes back. The reason I had it unchecked is because after upgrading confluence SSO would not work with it. So my options are:
1) consistent client IP address - Set that to yes and SSO wont work on confluence.
2) consistent client IP address - Uncheck that, SSO will work confluence but then when logging out of Jira, Confluence etc., the user remains logged in to BitBucket (and they think they are logged out which now becomes a security concern).

Is this a bug or is there a configuration issue? One note Crowd, Stash and Jira are using AJP connectors. Confluence is using a reverse proxy. Can this have anything to do with my issue of SSO not working with Confluence?

Dovid Bender · Answer

BUMP!

Dovid Bender · Answer

Sorry for not being clear. We are using Atlassian's crowd. Before posting the logs here.

1) What information other than the IP and my email should I scrub before posting it?
2) How do I post the lots so that they format correctly here?

Jon Espen Ingvaldsen Kantega SSO · Answer

Hi @Dovid Bender

SAML Single Logout (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. Basically any kind of architecture based around global session state and semi-regular polling or a more robust/bespoke notification/event mechanism.

So to sum up, SLO is the feature you are looking for here, but not all SSO vendors and IdPs supports this. Which IdP do you integrate with?

I work for Kantega SSO, one of the marketplace SSO vendors supporting SLO. You can try the product for free, and our support team is happy to help you setting up SLO in your Bitbucket environment.

Regards,
Jon Espen 
Kantega SSO