
Documentation for Crowd 1.0. Documentation for other versions of Crowd is available too.
Atlassian's popular JIRA issue management system takes advantage of the OSUser framework and can quickly be configured to use OSUser to link in single or multiple directory servers through Crowd. Crowd provides integration libraries for the OpenSymphony OSUser module, which has a simple-to-use API for user-management that allows pluggable implementations. More about the OSUser API can be reviewed at http://www.opensymphony.com/osuser/.
Currently Crowd supports centralised authentication and single sign-on for JIRA versions 3.8 and later.
CROWD.JIRA. For the purposes of this document, we will assume that the 'standalone' (i.e. the easier and recommended) installation method of JIRA has been used. If you need to install JIRA as an EAR/WAR, simply explode the EAR/WAR and make the necessary changes as described below, and repackage the EAR/WAR.The JIRA application will need to locate users from a directory configured in Crowd. You will need to set up a directory in Crowd for JIRA. For information on how to do this, see 2.2 Adding a Directory. We will assume that the directory is called JIRA Directory for the rest of this document. It is possible to assign more than one directory for an application, but for the purposes of this example, we will use JIRA Directory to house JIRA users.
JIRA also requires particular groups to exist in the directory in order to authenticate users. You need to ensure that these three groups exist in the JIRA Directory:
jira-usersjira-developersjira-administratorsYou also need to ensure that the JIRA Directory contains at least one user who is a member of all three groups. You can either:
Crowd needs to be aware that the JIRA application will be making authentication requests to Crowd. We need to add the JIRA application to Crowd and map it to the JIRA Directory.
Attribute |
Description |
|---|---|
Name |
The username which the application will use when it authenticates against the Crowd framework as a client. This value must be unique, i.e. it cannot be used by more than one application client. |
Description |
A short description of the application. Note: a web URL is often helpful. |
Active |
Only deselect this if you wish to prevent all users (from all directories) from accessing this application. |
Password |
The password which the application will use when it authenticates against the Crowd framework as a client. |
Default Directory |
A directory that contains relevant users. Note: additional directories can be added later. |
The Name and Password values must match the application.name and application.password that you set in the
JIRA/atlassian-jira/WEB-INF/classes/crowd.properties (see Step 2 below).
Now that Crowd is aware of the JIRA application, Crowd needs to know which directories or users can authenticate (log in) via Crowd. You can either allow entire directories to authenticate, or just particular groups within the directories. In our example, we will allow the jira-users, jira-developers and jira-administrators groups within the JIRA Directory to authenticate:
jira-users group will be able to authenticate against JIRA.jira-administrators group will be able to use the JIRA administration console.For details please see 3.4 Specifying which Groups can access an Application.
Please see 3.5 Specifying an Application's Address or Hostname. Please note:
localhost.localhost is a permissible foreign host. However, you will also need to manually add the IP address 127.0.0.1, as incoming requests to Crowd from JIRA (both on the same, local, host) may be from the host 127.0.0.1 and not localhost. Crowd does not do a DNS lookup of the hostname, rather, it compares the values as is. Ensure the "Status" field is set to "true".
JIRA needs Crowd's client libraries in order to be able to delegate user authentication to the Crowd application. As stated earlier, we are going to be modifying the JIRA application by editing the standalone application, which is an exploded WAR stored in JIRA/atlassian-jira.
Copy From |
Copy To |
|---|---|
CROWD/client/*.jar |
JIRA/atlassian-jira/WEB-INF/lib |
CROWD/client/conf/crowd.properties |
JIRA/atlassian-jira/WEB-INF/classes |
CROWD/client/lib. All the required libraries from there already exist in JIRA versions 3.7.4 and later.JIRA/atlassian-jira/WEB-INF/classes/crowd.properties. Change the following properties:
Key |
Value |
|---|---|
application.name |
jira |
application.password |
set a password |
crowd.server.url |
crowd.properties file are not used by JIRA.Now that the Crowd client libraries exist, we need to configure JIRA to use them.
JIRA/atlassian-jira/WEB-INF/classes/osuser.xml. Comment out any existing authentication providers and uncomment/insert the Crowd providers:
<!-- This is where JIRA's credentials checking can be configured. For instance, see
http://www.atlassian.com/software/jira/docs/latest/ldap.html -->
<opensymphony-user>
<authenticator class="com.opensymphony.user.authenticator.SmartAuthenticator" />
<!-- You will need to uncomment the Crowd providers below to enable Crowd integration -->
<provider class="com.atlassian.crowd.integration.osuser.CrowdCredentialsProvider"/>
<provider class="com.atlassian.crowd.integration.osuser.CrowdAccessProvider"/>
<provider class="com.atlassian.crowd.integration.osuser.DelegatingProfileProvider">
<property name="provider-1">com.atlassian.crowd.integration.osuser.CrowdProfileProvider</property>
<property name="provider-2">com.atlassian.jira.user.ExternalEntityJiraProfileProvider</property>
<property name="provider-2-exclusive-access">true</property>
</provider>
<!-- CROWD:START - The providers below here will need to be commented out for Crowd integration -->
<!--
<provider class="com.atlassian.core.ofbiz.osuser.CoreOFBizCredentialsProvider">
<property name="exclusive-access">true</property>
</provider>
<provider class="com.opensymphony.user.provider.ofbiz.OFBizProfileProvider">
<property name="exclusive-access">true</property>
</provider>
<provider class="com.opensymphony.user.provider.ofbiz.OFBizAccessProvider">
<property name="exclusive-access">true</property>
</provider>
-->
<!-- CROWD:END -->
</opensymphony-user>
JIRA/atlassian-jira/WEB-INF/classes/propertyset.xml. If an entry doesn't exists for the CrowdPropertySet, to add the following <propertyset> at the end of the file as the last <propertyset>:
<propertyset name="crowd" class="com.atlassian.crowd.integration.osuser.CrowdPropertySet"/>
JIRA/atlassian-jira/WEB-INF/classes/seraph-config.xml. Change the authenticator node to read:
<authenticator class="com.atlassian.crowd.integration.seraph.JIRAAuthenticator"/>
Once the setup is complete, go to the JIRA Administration Console. In the General Configuration section, turn on 'External User Management' and 'External Password Management' (see the JIRA Administrator's Guide for details). This means that the following functions can no longer be performed from within the JIRA administration interface: adding users, adding groups, editing users, editing groups.
jira-users group. Try adding a principal to the group using Crowd — you should be able to login to JIRA using this newly created principal. That's centralised authentication in action!jira-administrators group to the crowd application (see 3.3 Mapping a Directory to an Application and 3.4 Specifying which Groups can access an Application). This will allow JIRA administrators to log in to the Crowd Administration Console. Try logging in to Crowd as a JIRA administrator, and then point your browser at JIRA. You should be logged in as the same principal in JIRA. That's single sign-on in action!DataAccessException. The current workaround for this is to deactivate the principal's account (by removing them from the jira-users group). This issue can be tracked here: http://jira.atlassian.com/browse/CWD-202