03/21/2017 / 0 Comments
There are two options for using a SSO for Atlassian JIRA and Confluence:
Both options are possible with the JIRA Service Desk as well as the Data Center Version of the systems.
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
For the installation either a new Confluence system(A) or an existing Confluence system (B) can be linked to JIRA.
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
The wizard then finished the installation process and configures a administrator account with the same login data as the JIRA administrator account previously provided.
To connect an existing Confluence system with JIRA, JIRA needs to be able to process requests from Confluence.
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.
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.
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.
Do you have any questions? Don’t hesitate to contact us.
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.
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.
Want to learn more about SecSign’s innovative and highly secure
solutions for protecting your user accounts and sensitive data?
Use our contact form to submit your information, and a SecSign sales representative will contact you within one business day.
If you need assistance with an existing SecSign account or product
installation, please see the FAQs for more information on the most common questions. You don’t find the solution to your problem? Don’t hesitate to contact the
I am Interested in