Jira and Stash SSO Conflict

[Jim Pickering]

I am using Jira 6.2, Confluence 5.4.3, Fisheye/Crucible 3.3.1, and Stash 3.3.1 SSO with Crowd 2.7.1 on Windows Server 2008 R2 64-bit. The SSO part works with all of our Atlassian products. However, it seems it is Stash against the rest of the Atlassian apps. Once Stash is accessed via SSO, it takes a minute or two but then returning to Jira, Confluence, or Fisheye requires a login. If Stash is accessed first, then Jira, Confluence, Fisheye SSO works, however returning back to Stash, after a minute or two, then requires a login. I said a minute or two, because the apps appear to work for a minute, until then suddenly display the login screen. No other two Atlassian apps seem to have this trouble.

I have tried clearing all of the cookies from all of the apps, to get a fresh start, but the issue persists, and happens consistently.

Any ideas why Stash seems to kick the others out of SSO? This happens in both production and test environments.

[Jim Pickering]

An update to this issue, I have verified that running Stash on the same server as Crowd, Jira, Confluence, and Fisheye-Crucible allows Crowd SSO to work fine between all of the apps.

However, if Stash is running on a separate server (or VM) from Crowd, then it gets a different crowd.token_key than the other Atlassian Dev Tools running on the same server as Crowd. This is what causes the conflict.

I am opening a support ticket for further investigation.

[Caspar Krieger]

They should be using the same SSO library (especially JIRA, Confluence, and Stash, which reuse a lot of Crowd's own code), so I would initially suspect it's a configuration issue rather than a bug. Have you checked that the crowd.properties files are identical (except for app names & passwords)?

If that doesn't get you anywhere then I'd raise a support case ; each product is likely on a different version of the shared libs (so it could be a bug) but it's quite hard to tell "from a distance" here.

[Jim Pickering]

Jira and Confluence have crowd.properties files and properly adjusted seraph.xml files in WEB-INF/classes directory. Fisheye has crowd properties in the config.xml. The SSO works between those apps.

Stash, however, does not have a crowd.properites file and I didn't see in the documentation that it required it. Can you verify that?

Stash has SSO enabled in the stash-config.properties file in StashHome/shared. Also Stash is the only Atlassian app running on a different server, than the others. The others including crowd are running on the same server. Each application's Remote Address tab in Crowd is set properly though.

[Caspar Krieger]

Yep, you're right, Stash doesn't have a crowd.properties and uses stash-config.properties instead, as you mentioned. That actually implies there's less common code between Stash and JIRA/Confluence (as far as the authentication logic goes) than I thought (I'm a Crowd developer so I don't dive into the other products generally).

Stash running on a different server is something I would investigate. If you bring up JIRA and configure it for SSO on Stash's server, does it work? That would identify whether it's stash-specific or specific to your setup.

A more lightweight avenue of investigation is to look at the cookies set in your browser: as you browse around JIRA, Confluence and Crowd they should be sharing a Crowd cookie, and ideally Stash would be sharing the same cookie, but I suspect it might instead be setting its own one which overwrites the one the other apps are setting (and vice versa).

[Caspar Krieger]

Oh, one other thing I forgot to mention: the apps generally cache the session validation in their tomcat session for a minute or two; I suspect that's why you see the apps still working but then they suddenly stop working. In Stash, for example, this seems to be the property "plugin.auth-crowd.sso.session.validationinterval" (from https://confluence.atlassian.com/display/STASH/Connecting+Stash+to+Crowdwhich I have no doubt you've already spent some time staring at)

[Jim Pickering]

@Caspar

We have a test instance running the latest versions of Jira, Confluence, Fisheye/Crucible, Stash, and Crowd all on the same server. I tested the SSO and looked at the cookies, and everything works as expected; nothing looked out of place.

Then I looked at the cookies for the Production versions and noticed that the Confluence JessionID appears along with the Stash JessionID. Doesn't matter if I am logged into Confluence in that browser or not; it is always there with Stash. While I find this peculiar, I do not know if it is the cause of the issue; it is the only difference though.

Tried a different browser for Production. Logged into Stash first, the Confluence JSessionID appears with the Stash JessionId(even though I am not logged into Confluence and never used Confluence in this browser), along with a crowd.token_key and AJS.conglomerate.cookie. Tried to bring up Jira in a second tab, SSO did not work; however the crowd.token_key exists (without logging in) and matches the Stash crowd.token_key. So I manually logged into Jira, the crowd.token_key changed. Went back to the Stash tab, and refreshed, the crowd.token_key changed to match the newer Jira crowd.token_key. Stash is still displaying a Confluence JsessionId along with a Stash JessionId.

Questions: 1) How is it possible that Stash is getting a JessionId from Confluence, when each apps is running on a different server?

2) Jira is showing an atlassian.xsrf.token, but Stash isn't. Any idea what that is for?

Thanks,

Jim Pickering

[Caspar Krieger]

#1, no idea. It would be normal for your browser to send the JSESSIONID cookie to both apps regardless of which one it came from if they are on the same domain (/ host - which is from memory is configurable in the tomcat configuration). I'd guess that JSESSIONID is a red herring though - for SSO purposes it's only used to cache authentication (and if the wrong JSESSIONID cookie is read, then it just means that the token in the crowd.token_key cookie has to be verified with Crowd again).

#2, it's used as a form of CSRF protection. Not relevant for this.

I would say the changing crowd.token_key is the relevant symptom here. I strongly suggest you open a support case to troubleshoot this further. Our supporters are actually pretty friendly, and you can point them to this for context :)