Single Sign-on Integration with the Atlassian stack
A Single Sign On system allows users to use a single login for multiple applications. You can integrate JIRA and Confluence with the following SSO systems:
Crowd (Recommended) - Atlassian's single sign-on, authentication, authorization, application provisioning and identity management framework - see the Crowd documentation for more information on Crowd SSO and integrating it with Atlassian applications
Looking for a multi-domain SSO solution?
Look no more! Crowd SSO 2.0 offers one solution for Server, Data Center, and Cloud applications and setting it up takes only minutes.
Are you are ready for the change? See Crowd SSO 2.0.
Additionally, people have reported some degree of success integrating the following SSO systems with JIRA and/or Confluence:
The content on this page relates to platforms which are not supported for Confluence and JIRA. Consequently, Atlassian can not guarantee providing any support for these solutions.
Please be aware that this material is provided for your information only and using it is done so at your own risk. Note that Crowd, as an Atlassian product, is supported.
Writing a custom authenticator
JIRA and Confluence integrate with SSO system Seraph, the Atlassian authentication library. Seraph is a very simple, pluggable J2EE web application security framework developed by Atlassian and used in our products.
Seraph allows you to write custom authenticators which will accept the login credentials of your existing single sign-on system.
A few tips for writing your own custom authenticator for Confluence:
- For Confluence 2.2 and above you must extend
com.atlassian.confluence.user.ConfluenceAuthenticatorinstead of the Seraph
- The authenticator should not be a plugin. It should be placed in the class path by putting it in
WEB-INF/classesor as a jar in
- The authenticator should have a public constructor that takes no arguments.
- Dependency injection via setters or auto-wiring by name is not available to authenticators. Use
- The authenticators are constructed before beans are available via
ContainerManager.getInstance(...), so the
getInstancemethod needs to be called at runtime and not in the constructor.
These same restrictions apply for JIRA as well, except that:
- The base class to use is
- Components are obtained with
Existing custom authenticators
Check out these examples:
- CAS for Confluence, contributed by Carl Harris at Virginia Tech.
- CAS for JIRA, contributed by Carl Harris at Virginia Tech.
- Siteminder for Confluence, contributed by Ricardo Sueiras
- Shibboleth Plugin
- Kantega SSO for JIRA
- Kantega SSO for Confluence
- Kantega SSO for Bitbucket
- Kantega SSO for Bamboo
- Kantega SSO for Fisheye/Crucible
- EasySSO for JIRA - Keberos, NTLM
- EasySSO for Confluence - Kerberos, NTLM
- EasySSO for Bitbucket - Kerberos, NTLM
- EasySSO for Fisheye/Crucible - Kerberos, NTLM
- EasySSO for Bamboo - Kerberos, NTLM
- IWAAC Kerberos SSO
- SAML Single Sign On (SSO) Jira
- SAML Single Sign On (SSO) Confluence
- SAML Single Sign On (SSO) Bitbucket
- SAML Single Sign On (SSO) Bamboo
There has been discussion of integrating with Siteminder on the mailing list that may be applied to JIRA integration. All third-party code must be treated with caution - always backup your Confluence instance before use. If you create a custom SSO plugin and would like to contribute it to the user community, please let us know on a support ticket.
Using Confluence and JIRA without SSO
Confluence can also delegate user management to use JIRA logins , but this will not provide you with SSO.
Atlassian Data Center and SSO
For information relating to SSO and Atlassian Data Center, you can also have a look at our Sign-on for Atlassian Data Center applications article.