security

Atlassian Jira & Confluence Server – Architecting True SSO

Ajay Furber

• 3 min read

Update July 2022: Atlassian have announced the end of support for the Jira and Confluence Server Licences from 2024. As a result I have decommissioned all of our Atlassian Infrastructure and can no longer confirm that the Architecture below is still suitable. For full info, please see the Atlassian documentation here.

Within ayloNet, we use Azure Active Directory to provide all of our authentication services throughout our network. From End User kit, right through to inter-service communication, access is centralized and audited using Microsoft’s powerful tools.

When we deployed Jira and Confluence in to our environment, it was vital that we could integrate these applications in to our existing authentication and monitoring tools. The major problem is that we were using the (now off-sale) Jira/Confluence server products, rather than the Data Centre or Cloud Equivalents. This means that there is no native SAML or OAuth support within these tools* and a third-party solution was required.

We trialed a number of solutions including Microsoft’s own Azure AD connector for Jira but we found a number of problems:

  • The synchronisation of Azure AD groups (used to control access to roles, privileges and data) was not consistent or reliable.
  • Administrative users needed to retain a local password in order to access the secure parts of Jira.
  • There was no automatic redirect to the IDP which led to a non-ideal user journey.

After a detailed analysis of the options, we determined that we needed to deploy two separate solutions:

  • Atlassian Crowd: An Atlassian specific product used for managing the synchronisation of groups, users and passwords between multiple Atlassian applications in the same environment. This tool features Azure AD synchronisation for users and groups allowing automatic provisioning.
  • This product does not provide full SSO functionality within the Server products but reliably manages the provisioning process.
  • MiniOrange SAML for Jira/Confluence: This product actually handles the authentication with the IDP (Azure AD), manages the security tokens and authenticates administrative users when they access secure areas of the application.

The flow of data between the applications can be seen below.

Fig 1: Authentication Architecture for Atlassian Server Applications
Fig 2: Data Exchange*

* “Login via SAML” covers the full SAML authentication flow which can be seen in more detail here.

Provisioning

The provisioning process occurs automatically every 20 minutes. THis is initiated by the Atlassian Crowd server which calls the Azure Active Directory using the Microsoft Graph APIs to add all users and groups from the AAD to the Crowd Local Directory. All user group memberships are also updated every 20 minutes.

Once the users/groups are provisioned in Crowd, they are automatically pulled in to the Jira and Confluence directories themselves using the Atlassian specific directory technology. This results in Crowd, Confluence and Jira all having a complete replica of the AAD directory including Users and Group Memberships.

The guide for configuring Azure AD synchronisation can be found here!

Login

Technically Crowd is capable of providing the actual login services as well by allowing users to use their Azure Active Directory credentials (using the Native Graph APIs), however we found that this didn’t reliably work with accounts that had 2FA enforced. It also resulted in a poor user journey.

Login is therefore handled by the MiniOrange SAML Connector for Jira Server. This connector acts as a standard SAML Service Provider and is capable of both SP and IDP initiated sign-on. When the user accesses the Jira or Confluence server they are automatically redirected to the Azure AD sign on page (if they have not already been signed in to AD) within just a few seconds.

For Administrators who need access to secure areas, there is a “Login with %IDP Name% button on the Administrator Access page to ensure that authentication can be carried out without a specific application password as shown in Figure 2 below.

Access to Applications

As our Atlassian application licences are sparse, we also allocate these centrally so we have complete visibility of who has access to what application. This is done by changing the “Application Access” permissions to use a custom group (controlled only by AAD) rather than using the default jira-users or confluence-users groups which automatically provision licences.

Data Access

Data access is controlled using Azure AD groups that can be requested by and delegated to the owners of individual Jira Spaces or Confluence Projects, allowing them to manage who has access to which data. This is a transparent process and allows access to be managed from a single tool, rather than from each of the individual Atlassian applications.

* Atlassian Data Centre products feature in built SSO support and can configured following this guide.