nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira and Stash SSO Conflict

Jim Pickering2

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.

Accepted answers

All comments

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 Pickering2

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 Pickering2

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-server

crowd

sso