How does the Single Sign On (SSO) with Atlassian JIRA and Confluence work?

There are two options for using a SSO for Atlassian JIRA and Confluence:

• Option 1: Using JIRA as a centrally managed user management system for Confluence
• Option 2: Using Crowd as user management system for JIRA and Confluence

Both options are possible with the JIRA Service Desk as well as the Data Center Version of the systems.

Option 1: JIRA as centrally managed user management system for Confluence

The user management database of the JIRA system can be used for Confluence to simplify user management. There are some restrictions to using this method.

When a user is created in JIRA he receives the group affiliation “jira-software-users”/“jira-users” and can access Confluence without further configuration. However, if the user is created in Confluence he receives the group affiliation “confluence-user”. He can only sign into Confluence, not JIRA. To be able to access JIRA the user needs to be added to the group “jira-software-users”/“jira-users” manually.

Options for the configuration

For the installation either a new Confluence system(A) or an existing Confluence system (B) can be linked to JIRA.

Option A: Setting up a new Confluence system

During the Confluence server setup the installation wizard prompts the option to transfer the user management from a JIRA System. JIRA and Confluence do not have to run on the same server but can be managed on connected servers as well.

During the installation process the URL of the JIRA server has to be provided.

Also, the login data for the JIRA admin account need to be provided.

Additional adjustments can be added, for example using a proxy server or specifying a privileged group if it’s supposed to be different than standard groups. For new JIRA versions for example the standard group is called “jira-software-users” instead of “jira-users”.

The wizard then finished the installation process and configures a administrator account with the same login data as the JIRA administrator account previously provided.

Option B: Working with an existing Confluence system

To connect an existing Confluence system with JIRA, JIRA needs to be able to process requests from Confluence.

JIRA configuration

Open the user management tab in the administration menu in the upper right corner. Select the entry JIRA directory server on the left side. All applications with access rights to the JIRA directory are listed. By selecting “add application” access for Confluence can be added.

To grant access rights a login for the application needs to be configured. The username and password are later used in Confluence.

Also, the Confluence server URL has to be provided so JIRA can associate the request and process it accordingly.

The configuration is finished by saving the changes and in the next step, the Confluence system can be set up.

Confluence configuration

Admin rights are required to connect an existing Confluence system with JIRA.
Open the user management tab in the Confluence admin menu in the upper right corner. Select user directories in the tab “user and security”. A list of the connected directories is displayed. Normally, only the internal directory “confluence internal directory” should be visible. A new directory can be added by selecting “add directory”. Select Atlassian-JIRA as type and continue with the configuration.
First, add a name for the directory to be able to identify it later.

Also, the JIRA server URL is required as well as login data that have been specified earlier.

The remaining text boxes are optional and can be used if standard settings need to be changed or a proxy server is used.

Also, the reading and editing rights for Confluence need to be established.

If read-only is selected no user can be created, saved or deleted in Confluence. Only existing users can use the authentication. The directory can only be changed via JIRA.
If editing rights are granted, the directory can be changed via Confluence and users can be added or deleted, without logging into JIRA first.

With the advanced settings nested group can be created. This may have an effect on the performance of the system since additional references may have to be resolved.
The incremental synchronization can be disabled to simplify the synchronization. That way only the most recent changes are booted, not the entire directory.

The synchronization interval determines how often the directory is updated. The synchronization can be booted manually at any time.

The settings are now tested and saved.

Storage in an internal directory

User data can either be exclusively obtained from JIRA or Confluence can receive a local directory. The local directory should be used if read-only access was granted. Otherwise, no user can be created in Confluence and every account needs to be generated via JIRA. Also, an admin should be left in the Confluence directory for tending problems if the connection to JIRA is dropped.

If an individual directory is selected the order of directories can be set. The top directory is used first to resolve requests. Changes are stored in the first directory Confluence has access rights to.
The internal Confluence directory can only be deleted with the JIRA admin account.

The configuration of the JIRA and Confluence link is completed and Confluence uses the JIRA directory for logins.

Option 2: Using Crowd as user management system for JIRA and Confluence

To simplify the user management even more JIRA and Confluence can be linked with Crowd. The advantage of this procedure compared to the user management with JIRA is the possibility to use Crowd for authentication of different services as well. It offers a centrally managed user management system for all used applications.

Link with existing directory services

With Crowd, existing directory service can be integrated and used for other applications and services like JIRA and Confluence and other Atlassian services. Examples for supported directory services include Microsoft Active Directory, Apache Directory Server and Apple Open Directory. There are numerous more directory services that can be used with respective adjustments.

Most directory services can be either used as read-only application with no changes possible to the directory or as a read-and-edit option. Latter makes direct changes to the directory service via Crowd or other applications possible, which reduces some administration effort.

As soon as the respective directory is linked to Crowd access to applications can be granted to the users by assigning them to predefined groups. Alternatively, new groups can be generated and access can be limited to those clusters.

How does the Login with Crowd work?

There are no changes for the user, the changes are limited to the background and not visible to the user.

Depending on the settings the users and groups from the external directories are cached in Crowd to allow for faster retrieval of information, for example when a group or the user of a group is displayed.

The login with an external directory service is always authenticated with the respective directory service. No passwords are synchronized from the directory service and are only used for authentication via the interface. The passwords remain with the directory at all times.

Crowd as centralization or encapsulation

Crowd offers a graphically efficient admin console for easy administrator activity.
It also offers the possibility to generate additional directories, for example for the link to JIRA, that locally only contains users known to JIRA. That way user groups with access only to one product can be generated. Also, those groups can be managed directly via the product, for example JIRA, without effect to other directories.
Thus, Crowd allows for a centralization of user data as well as an encapsulation of individual groups and applications. Basically any scenario of user management requirements can be realized.