Documentation for Crowd 2.7. Documentation for earlier versions of Crowd is available too.

Skip to end of metadata
Go to start of metadata

Currently Crowd supports centralised authentication and single sign-on for JIRA versions 3.7.4 and later.

Please check that this documentation applies to your version of Crowd

Icon

Please check the Crowd release number in this documentation against your version of Crowd. If you are using a different version of Crowd, you can find the appropriate documentation under 'Previous Versions' on the Crowd documentation homepage.

On this page:

Compatibility of JIRA and Crowd Versions

Please ensure that your Crowd and JIRA versions are compatible:

  • If you are using JIRA 4.2 please upgrade to Crowd 2.0.7 or later. (watch out for Crowd 2.4 though:  JRA-27890 - Crowd 2.4 is not compatible with JIRA 4.2.4 Resolved )
  • If you are using JIRA 4.3 or later, please upgrade to Crowd 2.1 or later.
    Explanation: With JIRA 4.3 and higher, the communication between JIRA and Crowd has been changed from SOAP to REST.

Prerequisites

Icon

Do not deploy multiple Atlassian applications in a single Tomcat container.

Deploying multiple Atlassian applications in a single Tomcat container is not supported. We do not test this configuration and upgrading any of the applications (even for point releases) is likely to break it. There are also a number of known issues with this configuration. See this FAQ for more information.

There are also a number of practical reasons why we do not support deploying multiple Atlassian applications in a single Tomcat container. Firstly, you must shut down Tomcat to upgrade any application and secondly, if one application crashes, the other applications running in that Tomcat container will be inaccessible.

Finally, we recommend not deploying any other applications to the same Tomcat container that runs Crowd, especially if these other applications have large memory requirements or require additional libraries in Tomcat's lib subdirectory.

  1. Download and install Crowd. Refer to the Crowd installation guide for instructions. We will refer to the Crowd root folder as CROWD.
  2. Download and install JIRA (version 3.7.4 or later). Refer to the JIRA installation guide for instructions. We will refer to the JIRA root folder as JIRA. For the purposes of this document, we will assume that you have used the 'Crowd distribution (not EAR-WAR)' (i.e. the easier and recommended) installation method of JIRA. If you need to install JIRA as an EAR/WAR, simply explode the EAR/WAR and make the necessary changes as described below, then repackage the EAR/WAR.
  3. Run the JIRA Setup Wizard, as described in the JIRA documentation. During this setup process, you will define the JIRA administrator's username and password. It is easier to do this before you integrate JIRA with Crowd.
  4. For JIRA 4.2 or earlier: after setting up JIRA, shut down JIRA before you begin the integration process described below.
Icon

If you are using JIRA as a User Directory in any other applications such as Fisheye or Confluence these will be inaccessible while JIRA is shut down. You can avoid this by configuring these applications to use Crowd prior to integrating Crowd with JIRA.

 

Step 1. Configuring Crowd to talk to JIRA

1.1 Prepare Crowd's Directories/Groups/Users for JIRA

  1. 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. This directory may be any Crowd-configured directory, such as an LDAP directory hooked up to Crowd or a Crowd internal directory. For information on how to do this, see Adding a Directory.

    We will assume that the directory is called JIRA Directory in Crowd 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 in Crowd to house JIRA users.
  2. 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 in Crowd:
    • jira-users
    • jira-developers
    • jira-administrators
  3. You also need to ensure that the JIRA Directory in Crowd contains at least one user who is a member of all three groups. You can either:
    • If you have an existing JIRA deployment and would like to import existing groups and users into Crowd, use the JIRA Importer tool by navigating to Users > Import Users > Atlassian Importer. Select 'JIRA' as the Atlassian Product and the JIRA Directory in Crowd as the directory into which JIRA users will be imported. For details please see Importing Users from Atlassian JIRA. (info) If you are going to import users into Crowd, you need to do this now before you proceed any further.
      OR:
    • If you don't wish to import your JIRA users, use the Crowd Administration Console to create the three groups, then create at least one user in the JIRA Directory in Crowd and add them to the three JIRA-specific groups (above). The Crowd documentation has more information on creating groupscreating users and assigning users to groups.

Error will occur in JIRA if the required groups do not exist

Icon

JIRA expects that the group names mentioned above will exist. If you need to use different group names, you may want to remove the above pre-existing groups from JIRA's Global Permissions. If the above groups do not exist somewhere in Crowd, you will receive an error when you try to remove the groups from JIRA's Global Permissions.

1.2 Define the JIRA Application in Crowd

Icon

If multiple versions of JIRA are being connected to Crowd, ensure you define an application in Crowd for each one

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 in Crowd.

  1. Log in to the Crowd Administration Console and navigate to Applications > Add Application.
  2. Complete the 'Add Application' wizard for the JIRA application. See the instructions. (info) The Name and Password values you specify in the 'Add Application' wizard must match the application.name and application.password that you will set in the JIRA/atlassian-jira/WEB-INF/classes/crowd.properties file. (See Step 2 below.)

 

1.3 Specify which users can log in to JIRA

Once Crowd is aware of the JIRA application, Crowd needs to know which users can authenticate (log in) to JIRA via Crowd. As part of the 'Add Application' wizard, you will set up your directories and group authorisations for the application. If necessary, you can adjust these settings after completing the wizard. Below are some examples.

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 in Crowd to authenticate:


(info) With this example, only users who are members of the jira-users, jira-developers and jira-administrators groups will be able to authenticate against JIRA.

For details please see Specifying which Groups can access an Application.

1.4 Specify the address from which JIRA can log in to Crowd

As part of the 'Add Application' wizard, you will set up JIRA's IP address. This is the address which JIRA will use to authenticate to Crowd. If necessary you can add a hostname, in addition to the IP address, after completing the wizard. See Specifying an Application's Address or Hostname.

Step 2. Configuring JIRA to talk to Crowd

Icon

The instructions for step 2 below apply to JIRA 4.3 or newer. If you use JIRA 4.2 or older, please follow "Step 2" on Integrating Crowd with Atlassian JIRA 4.2 or earlier instead.

2.1 Add a Crowd Directory in JIRA

JIRA can use Crowd for user authentication simply by adding 'Atlassian Crowd' as user directory.

  1. Login to the administration section of JIRA
  2. Click on the 'User Directories' label of the left bar under the 'Users, Groups & Roles' tab.
  3. Click 'Add Directory'. Then select 'Atlassian Crowd' from the dropdown list. Click 'Next'.
  4. Enter connection parameters and save. If you configure Server URL to use HTTPS, by replacing http:// with https://, communications between JIRA and Crowd will be encrypted.
  5. Now a new Crowd directory should appear on the user directory list.

For more information on configuring a Crowd directory in JIRA, check out the JIRA documentation on Connecting to Crowd or Another JIRA Server for User Management.

2.2 Configure JIRA to use Crowd's Authenticator to enable SSO (Optional)

At this stage, JIRA is set up for centralised authentication. If you wish, you can now enable single sign-on (SSO) to JIRA. This will ensure that JIRA's authentication and access request calls will be performed using Seraph.

Note: if you are migrating/upgrading a JIRA instance that already uses Crowd, you will need to merge these files (not overwrite them).

  1. If JIRA is running, shut it down first.
  2. Edit the JIRA/atlassian-jira/WEB-INF/classes/seraph-config.xml file. Comment out the authenticator node:


    Uncomment the line that contains the new authenticator:

  3. Copy the crowd.properties file from CROWD/client/conf/ to JIRA/atlassian-jira/WEB-INF/classes.
  4. Edit JIRA/atlassian-jira/WEB-INF/classes/crowd.properties. Change the following properties:

    Key

    Value

    application.name

    jira
    The application name must match the name that you specified when you defined the application in Crowd (see Step 1 above).

    application.password

    The password must match the one that you specified when you defined the application in Crowd (see Step 1 above).

    application.login.url

    This should be set to the base URL of your JIRA server. Crowd will redirect users here if they need to authenticate.

    crowd.base.url

    eg. (http://localhost:8095/crowd/)
    If your Crowd server's port is configured differently from the default (i.e. 8095), set it accordingly.

    crowd.base.url must be the same URL used to access Crowd in your Browser.

    session.validationinterval

    Set to 0, if you want authentication checks to occur on each request. Otherwise set to the number of minutes between request to validate if the user is logged in or out of the Crowd SSO server. Setting this value to 1 or higher will increase the performance of Crowd's integration.

Icon

It is possible to define multiple user directories in JIRA. However, if you enable SSO integration, you will only be able to authenticate as users from the Crowd server defined in the crowd.properties file.

You can read more about optional settings in the crowd.properties file.

2.3 (Optional) Disable the Auto-Complete Function in JIRA's User Picker

To improve performance on page-loading in JIRA, we recommend that you disable the auto-complete function in JIRA's 'User Picker' popup screens. Follow the instructions in the JIRA documentation.

More information: In our experience, disabling this feature in JIRA helps performance for customers with extremely large user bases. If you leave this feature enabled and have adequate performance results in JIRA, feel free to leave it enabled.

See Crowd in Action

  • You should now be able to login using users belonging to the jira-users group. Try adding a user to the group using Crowd — you should be able to login to JIRA using this newly created user. That's centralised authentication in action!
  • If you have enabled SSO, you can try adding the JIRA Directory in Crowd and jira-administrators group to the crowd application (see Mapping a Directory to an Application and 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 user in JIRA. That's single sign-on in action!

Known Limitations

If you are using JIRA 4.2, a problem occurs in JIRA if a user is removed after that user has participated in an issue i.e. if JIRA refers to the user. If the user is internally managed by JIRA, JIRA will prevent the removal of the user but if the user is managed by an external system such as Crowd, JIRA will throw a DataAccessException. We recommend upgrading JIRA or deactivating the user's account by removing them from the jira-users group.

If you are using JIRA 4.3 or later, this problem has been resolved, allowing the removal of users that are externally managed, despite existing data associations. When a user managed by an external system such as Crowd is removed, any user associations in JIRA will continue to be associated, with the username acting as a placeholder. This username will not be listed in the User Browser and no profile exists for that user. 

RELATED TOPICS

Crowd Documentation

  

8 Comments

  1. If you need to install JIRA as an EAR/WAR, simply explode the EAR/WAR and make the necessary changes as described below, then repackage the EAR/WAR.

    So does this mean that I can't simply add crowd.properties to the atlassian-jira-4.3.3-war/edit-webapp/WEB-INF/classes directory and rebuild the war? I assume so since this file is not getting copied into my war file. I have to re-add this every time I re-compile the war?

  2. From section 1.1.2 Above:

    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 in Crowd:

    Through my experience I have found that is not true, and for users connecting to existring LDAP directories adds needless hassle.

     

    Instead it should be an option to either:

    1. Add the 3 pre-defined groups to crowd OR
    2. Use 2-3 existing groups in your' company's directory, add those directly to Jira (internal directory) and then assign permissions on the permission page.
      As long as each permission has a group that exists in LDAP, and the decided "admin user" belongs to all thos groups, there is no need for the predfined names. 
  3. There is a little bug if you are using crowd 2.4 with JIRA 4.2.4: https://support.atlassian.com/browse/JSP-122102

    1. Looks like you linked the support issue, I believe you wanted to link this bug report:  JRA-27890 - Crowd 2.4 is not compatible with JIRA 4.2.4 Resolved

  4. CWD-202 is a little bit confusing, in that it has a status of Resolved, a resolution of Won't Fix ... and yet the last comment by David O'Flnn says that JIRA 4.3 resolves the issue! JIRA apparently creates placeholders for those people associated with an issue but who don't have a profile.

    So both this page and the bug could do with a bit of work to make it less confusing.

     

    1. Thanks for picking that up Philip, the page has been updated to reflect the fix that was in CWD-202.

  5. Based on what I'm reading, it sounds like it should be fine to use bcrypt with Atlassian Crowd and have it still function with JIRA without issue? Can someone from Atlassian please confirm this? The wording on the Crowd install is still very ominous:

    "For compatibility between Atlassian products you must use ATLASSIAN-SECURITY."

    1. Yes, that's fine. See  CWD-3812 for clarification.