Set up Atlassian applications as the SP and EAA as the IdP

How to set up Atlassian applications as service providers (SP) and EAA as the identity provider (IdP).

Before you begin

This procedure assumes that your Atlassian applications are currently integrated with Crowd SSO and you want to extend the SSO functionality through EAA by using third-party SAML plug-ins for the Atlassian Suite.

There are several SAML plug-in providers for Atlassian products. This example uses the plug-ins provided by Kantega for the following applications:
  • JIRA Server
  • Confluence Server
  • Bitbucket Server
  • Bamboo Server
  • Fisheye/Crucible

This sample procedure goes through the steps required to integrate Confluence as an SP and EAA as an IdP. You can use this procedure with other compatible Atlassian applications with only minor revisions if any are required.

How to

  1. Disable Crowd SSO functionality. When you first try to configure the Kantega Plugin, you receive a warning that the seraph-config.xml file needs to be updated to use the standard Confluence authenticator, rather than the Crowd SSO authenticator which was configured as part of the Crowd SSO setup process. To resolve this error:
    1. Shut down the Confluence instance.
    2. Locate the seraph-config.xml configuration file. For this example it is in the following Windows directory:
      C:\Program Files\Atlassian\Confluence\confluence\WEB-INF\classes
    3. Comment out the line that sets the Crowd SSO authenticator and uncomment the line which sets the default Confluence authenticator. For example, a working configuration in seraph-config.xml should look like this:
      <!-- Default Confluence authenticator, which uses the configured user management for authentication. 
      <authenticator class="com.atlassian.confluence.user.ConfluenceAuthenticator"/>
      <!-- Custom authenticators appear below. To enable one of them, comment out the default authenticator above and uncomment the one below. -->
      <!-- Authenticator with support for Crowd single-sign on (SSO).
      <!-- <authenticator class="com.atlassian.confluence.user.ConfluenceCrowdSSOAuthenticator"/>
    4. Start the Confluence instance again.
    5. After the Confluence instance starts, log in with a Crowd directory user to ensure that access is working correctly. You should no longer see any warning messages about an invalid authenticator being used when you check the Kantega Single Sign-on Configuration page.
  2. Configure Confluence by accessing the Kantega SSO add-on and under the SSO with SAML option, select Any SAML 2.0 Identity Provider.
    Kantega SSO screen

  3. From that screen, copy the ACS URL, Entity ID, and Certificate text into a notepad for later use and click Next.
    Kantega certificate

  4. Create a new application on EAA. See Configure EAA as the IdP for a custom SaaS application to complete the regular application configuration.
    1. Select an Identity Provider and Directory that contains the same user information as your Atlassian Crowd directory.
    2. Click Advanced settings > Authenication > Application-facing Authentication mechanism tab.
    3. Select SAML from the menu and select whether to use a self-signed (default) or custom certificate to sign SAML responses.
    4. Click Save and go to SAML Settings.
      Atlassian EAA Advanced settings

    5. Download the IdP certificate file.
    6. Paste the Kantega Entity ID and ACS URL values you copied earlier into the corresponding fields on the SAML SETTINGS page.

    7. Modify NameID Format and NameID Attribute to control how the user (Subject) is identified in the SAML Assertion. In this example, my Crowd directory users use their domain userPrincipleName (UPN) as their username, so update the EAA configuration as follows:
      Atlassian EAA name attributes

    8. You can leave Default Relay State blank.
    9. Click Signed Request to indicate that the SAML Request from Confluence will be signed. Paste the certificate you copied earlier from the Kantega configuration into the Request Signing Certificate box.
    10. Leave Response Encryption unchecked.
    11. The rest of the configuration options can be left as default. Click Save and go to Deployment.
  5. Continue to configure Confluence as the SP:
    1. Upload the EAA IdP metadata file to the Kantega configuration and click Next.
    2. Give the IdP a suitable name. The SSO redirect URL should be automatically set from the metadata file. Click Next.
    3. Verify the IdP signature and click Next.
    4. Decide what should happen if a SAML Assertion is received by Confluence for a user without an existing Confluence account. In this example, select Accounts already exist in Confluence when logging in and click Next.
      Atlassian Confluence account

    5. Verify that the IdP configuration summary is correct and click Finish.
    6. Go back to the Kantega SAML Configuration Menu. Under Settings > Known Domains, add a list of trusted domains that users are expected to log in with or alternatively, trust logins from all domains.
      Atlassian domains

    7. From Settings > Redirect Mode, decide how you want the redirection from Confluence to the EAA IdP to occur. For the most seamless experience, choose Always redirect users to this provider (do not show the login page).
    8. Click Save.
      Atlassian redirect

  6. After the EAA application is successfully deployed and the Kantega configuration is finished, you can use the EAA published application URL to test access.


In this example, navigate to where you are first redirected to EAA IdP to complete authentication and log in with a valid user account using the UPN name format. After this initial login has been completed, the SSO process between Confluence and EAA completes seamlessly and you will get authenticated access to Confluence without having to complete any additional login.

If you now access another Atlassian application that has been published through EAA as the SAML IdP, SSO completes and you gain authenticated access without having to complete any additional login steps.