-
Suggestion
-
Resolution: Low Engagement
-
None
-
None
-
3
-
Many SSO solutions integrate at the Tomcat layer by passing an authenticated user(name) to Tomcat. Inside the web application, this username is available through HttpServletRequest.getRemoteUser() and HttpServletRequest.getRemotePrincipal().
Stash should accept this username as already authenticated and transparently log the user in with that username.
Presumably, the SSO solution provides an external login page. Stash should redirect the user to a configurable login URL when authentication is required.
Likewise, when the user logs out in Stash, the SSO session should be terminated. The logout success URL should be configurable as well.
Finally, when a user has been authenticated using container managed authentication and the remoteUser name is no longer provided by the container, the user should be logged out of Stash.
Questions:
- Are the login and logout URLs optional or required?
- Can the Remote User be spoofed through HTTP headers? Most SSO integrations seem to rely on the AJP connector and not use the HTTP connector. Not sure whether that is for security reasons.
- Can container managed authentication support be enabled out of the box, or should it be explicitly enabled by sysadmins? Related to the previous questions.
[BSERV-3239] Support container managed authentication
FYI, there's an example authentication plugin available on https://bitbucket.org/mheemskerk/stash-auth-plugin-example/overview that inspects and authenticates the container-provided user. This should work for SSO solutions that integrate at the Tomcat/Apache level.
James
added a comment - CSIRO is expanding the use of the Australian Access Federation (AAF) for access by collaborators to our resources, including (hopefully) to shared source code. This allows our collaborators to authenticate with their home institution rather than us providing new credentials for them.
AAF is a Shibboleth based service and involves configuring Apache (and the shib plugin) in each system to provide container based authentication. Normally we will have a protected page which we redirect the client to which kicks off the sign-on process. Once the client has signed in they are redirected back to the site with headers to indicate their identity. Further information on setting up a service provider
Perhaps this use case could be covered by this feature?
James
added a comment - CSIRO is expanding the use of the Australian Access Federation (AAF) for access by collaborators to our resources, including (hopefully) to shared source code. This allows our collaborators to authenticate with their home institution rather than us providing new credentials for them.
AAF is a Shibboleth based service and involves configuring Apache (and the shib plugin) in each system to provide container based authentication. Normally we will have a protected page which we redirect the client to which kicks off the sign-on process. Once the client has signed in they are redirected back to the site with headers to indicate their identity. Further information on setting up a service provider
Perhaps this use case could be covered by this feature? BTW what most implementations of SSO via request headers do as the first thing is to unset any header with the same name that may come directly from the user. Of course to prevent them from spoofing an uid...
+1
Please make sure that the implementation is flexible enough to allow not only for container managed auth but via random request properties (easy to set from mod_jk via JkEnv) or even request headers for those using http proxying.
I don't know how "integrated" the teams are at Atlassian but something I would definitely like to have is some coordination across products in this aspect. At least JIRA would be absolutely necessary too, and Confluence almost. It would be nice to have Fisheye and Bamboo too.
What I mean by "integrated" is that all products have this feature and that all of them implement it in the same way. Now that would be useful! 
Daniel
Hello,
Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself.
Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap.
Please note the comments on this thread are not being monitored.
You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here.
To learn more about our recent investments in Bitbucket Data Center, please check our public roadmap and our dashboards, which contain recently resolved issues.
Kind regards,
Bitbucket Data Center