Page tree
Skip to end of metadata
Go to start of metadata

This space has been restricted - PUBLIC KB available here Single Sign-on Integration with the Atlassian stack



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.

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, authorisation, application provisioning and identity management framework

Additionally, people have reported some degree of success integrating the following SSO systems with JIRA and/or Confluence:

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 creditentials 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.ConfluenceAuthenticator instead of the Seraph DefaultAuthenticator.
  • The authenticator should not be a plugin. It should be placed in the class path by putting it in WEB-INF/classes or as a jar in WEB-INF/lib
  • 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 ContainerManager.getInstance(...) instead.
  • The authenticators are constructed before beans are available via ContainerManager.getInstance(...), so the getInstance method 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 ComponentAccessor.getComponent(...).

Existing custom authenticators

Check out these examples:

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.

Discussion Forums

Seraph Discussion Forums

Using Confluence and JIRA without SSO

Confluence can also delegate user management to use JIRA logins , but this will not provide you with SSO.




  1. Have some questions about custom authenticators written for use with an SSO:

    • As a best practice, what password should be populated in the user's password field if you are autoprovisioning (automatically creating) users as part of the authenticator that is using an SSO for authentication?
      • It seems that it could be a possible security risk to leave password null or even to assign any arbitrary value to it (unless it was very unique).
      • Leaving password null appears to be a problem (issue CONF-9117) with migration of os_user to atlassian-user.
    • What is the best practice to avoid the issue of two different nodes in a cluster both checking at the same time whether a user exists and automatically provisioning the user at the same time (which would cause a unique constraint exception to be thrown from the DB driver)?
    • Should there be any preference given to overriding/implementing login() vs. getUser() in the custom authenticator for this purpose? (getUser() gets called an awful lot, so for sure if you use that, you'll want to attempt to just get and return the user from session first.)
    • Are there any suggestions as whether UserManager or UserAccessor should be used for autoprovisioning users (or creating them in general) for each of the different versions of confluence (both version#, whether using massive, and whether using os_user vs. user-atlassian schema)?
  2. Is there a possibility to use SSO from a Microsoft ISA server for Jira and Confluence?

  3. We are using Confluence 2.7 with Siteminder for SSO.  How can I remove the "password" link in Preferences > Edit Profile so that users don't have the ability to change their password?

    1. Administration -> General Configuration -> Security and Privacy -> External User Management set to On

      1. Thanks for the response Roberto.  I don't want to turn External User Management on because I'd still like to manage my groups from within Confluence.  I was wondering how to remove the actual "password" link from the edit profile page.  I managed to find confluence-2.7.war/users/changemypassword.vm, but I'm not sure how to remove the link from the left-hand nav bar. 

        1. In that same vein - how can I remove the 'Forgot Password?' Link from the login page?

  4. CAS integration with the JASIG CAS Client for Java 3.1 (Confluence)

    I'm working on the JIRA integration guide.

  5. I can also confirm a successful test setup using the Confluence 2.10.3  + soulwing CAS client +  rubycas-server

    rubycas-server took some massaging to get running, but has been working fine since then.  The soulwing CAS client is also working like a champ so far.

  6. TechTime Initiative Group, an Atlassian Expert in New Zealand has been providing a solution to do NTLM authentication with Confluence and Jira for over 7 years. Though one can argue that this is not an SSO solution but merely an auto-login one, it works well in Windows-based environments.

    By now we have over 90 customers successfully using this solution in New Zealand, Australia, Switzerland, Finland, Norway, Sweden, France, Germany, Netherlands, Slovenia, Czech Republic, Turkey, Russia, Latvia, Brasil, the UK and the USA in NTLMv2 environments with and without Crowd in the backend.

    The solution has been recently migrated to be a v2 plugin downloadable from Marketplace as EasySSO for JIRA and EasySSO for Confluence.

    EasySSO works in conjunction with IOPlex Jespa - the only pure java library to perform NLTM authentication in Windows environment. The cost of IOPlex license is included in the price of EasySSO.

    We are currently working on adding Fisheye/Crucible, Bamboo and Stash authenticators.

  7. Note: the link titled "Shibboleth Plugin" should be now titled "Confluence HTTP Authenticator". Previously, it was called "Confluence Shibboleth Authenticator" and "Shibboleth Authenticator for Confluence". It was never really Shibboleth-specific. It is a fairly generic HTTP(S) SSO authenticator with some cool features.

  8. The hyperlink 'mailing list' is not working.

  9. A couple years ago we built a kerberos plugin for jira/confluence. The plugin is a version 2 plugin (you dont have to restart the application) and is built with a test tool for troubleshooting and also comes with help text to get you all up and running quickly. We have reached a point where we are thinking of selling ore providing the plugin for free. If there`s an interest for the plugin to be provided in any way, please send me an email at

  10. The plugin has just been released to Atlassian Marketplace. We wish to thank all the people that has provided useful feedback in the testing process. Feel free to test the plugin from Atlassian Marketplace from now on. Feedback is highly appreciated!

  11. We've also just released a Plugin which supports SAML 2.0 with JIRA & Confluence. Originally our sister companies have used it internally until we decided that it may be a useful product for a wider audience.

    Certainly feel free to test it via the Marketplace - if you want to purchase let me know and I create you a 50% discount code as an early adoptor. 



    1. Interesting, will look into it.

    2. Interesting, will look into it.

    3. Hi Chris,

      Your link seems dead. Is there an alternate link to check your solution?



      1. Hi Gilles Beraudo,

        yes certainly - we had to split the Plugin into a JIRA & Confluence Version due to Atlassian's payment backend.

        If you need any more Info, let me know or bounce us an eMail to

    4. Can someone remote this SPAM thread from here? This plugin was archived, so all the comments here are just spam.

      1. Dear Citrix DevOps,

        As mentioned in the discussion trail above, we had to split the plugin at Atlassian request, which is the reason why the original link has been archived and the two new Links I published in that above discussion are the current ones.

        Taking your comment however I also removed and updated the orginal post, so that no one needs to read the full discussion. Also for your convienience, here are the two plugin links once more:

        Hope that addresses your comment.



        1. Thanks for the update. Another configuration failure on CAC, we are not allowed to edit or remove our own comments (tongue)

          1. Hi, Go2Gorup has built an integration for CAC & PIV for JIRA, Confluence, Stash, and Bamboo as well as Crowd and the product is in us by DoD and others and is on the cleared list of products.

            See -


            It is in use by US NATO and similar countries.

  12. Authenticating via web app (PHP/etc) using Confluence HTTP Authenticator

    I've been looking to allow users to log in using their email address, rather than username for a while (as they kept forgetting their usernames...) - and finally figured out a way to do this thanks to the Confluence HTTP Authenticator

    I wrote up the instructions on how I did it, and code-samples, here:

    The example is very basic, and uses PHP to search for the email in the Confluence SQL user database to find the username, and then SOAP to authenticate against Confluence itself with the supplied password. But the approach I adopted to integrate with the the Confluence HTTP Authenticator could be used for all sorts of things – such as your own user database, provided you've store the users' confluence username in that, etc.

    It turns out for my purposes there's a much simpler way, without the need for the Confluence HTTP Authenticator plugin (as I have access to the user's password from the login form). But if you're you're authenticating against your own password database, rather than Confluence – then this code may be useful for you.

    1. Hey Mark! I appreciate you creating something up-to-date on our project wiki page about how to setup. Thanks! We can definitely use help in making it easier to use.

      A few things to note, although neither of these might be of concern, depending on your situation: (1) users sometimes need to change their email address, but want to keep a consistent username. If username were the email address, then whenever they need to change their email address, that would change the username, and anything using the username itself as an identifier (instead of the unique id of their user) would break. Also, if people were using that username to remember who you were for access assignment to a page, they would have to learn the new username. Historically in Confluence, content was assigned to username, not an id, which made this even more important, because changing a username would have meant updating a lot of rows in the DB. (2) Although this is less of a problem in Confluence because of the ability to show full name, if the username were the email address and were displayed, then it would be giving away the user's email address, which they may not wish to share.

      Even though setting up a custom authentication solution is fun and a great learning experience, there are many benefits to using Crowd, Shibboleth, Active Directory, etc. It can be a lot of overhead, and if it is, then using Confluence's built-in auth is a good option for many.

      Again, thanks much, and I'm glad that you found something that works for you. If you or anyone else want to continue to donate time and effort into the authenticator or its documentation, we can really use the help.

      1. Hi Gary - Good point about username/email, and it's easy enough to modify the SQL query/etc to search for for either/or both email and username. We're looking to not really promote/mention a username to users at all when they sign up (we create their account using the SOAP API from a separate signup wizard), as with the user "name" autocomplete in new versions it's not very necessary.

        As posted elsewhere, after I worked out how to use the SSO plugin – I figured out that for our purposes (as the user is actually typing their password in) we don't need to invoke the Confluence HTTP Authenticator plugin. But if you were brewing your own SSO solution, the plugin is obviously great - and has more advanced capabilities, such as updating email, name, etc with each login handover.

        For those of you looking for a very simple login using email address (instead of username) solution, I've published my latest little PHP hack for this here:


  13. I've written a blog post about my efforts to get SiteMinder SSO working with JIRA:


  14. Hi @Christian Reichert

    Is your plugin available for JIRA On Demand as well?

    1. Hi Rina Rockind,

      unfortunately On Demand does currently not allow for this kind of deep integration (sad). So it is a limitation of that platform.



  15. There are some Kerberos plugins missing in the list of "Existing custom authenticators"

    Kerberos plugin for JIRA

    Kerberos plugin for Confluence

    We have been using these plugins for almost a year now with great success (happy users and no trouble:) 

  16. Here is a blog which talks in details about integration of JIRA with SSO. Worth reading :

  17. Hi,

    We are proud to announce the release of our new add-on, Integrated Windows Authentication for Apps using Crowd (IWAAC) at

    IWAAC uses SPNEGO/Kerberos to allow your Windows domain users to log into Jira, Confluence, or any other web app using Crowd as its user management system without entering a password.

    Please check out for more details.

    Best regards,


  18. BTW, our CAC PIV CCA SSO solution for the Atlassian suite has received approval for secured systems!  and is certified by DoD and other agencies.