JIRA Server (On-Premise)

With Centrify as your Privileged Access Service, you can configure JIRA Server (On-Premise) for either or both IdP-initiated SAML SSO and SP-initiated SAML SSO (for SSO access directly through the JIRA Server web application). Enabling both methods ensures that users can log in to JIRA Server in different situations such as clicking through a notification email.

Note:   After you configure SAML SSO, JIRA username-password login pages will not function. It will display a login error even if the correct username and password are entered.

JIRA does not support SAML, but it accepts a custom plugin for individual companies to modify the authentication process to their own needs, including implement Single Sign-On. A custom plugin is a set of .jar files that are implemented using Atlassian's Seraph library, and will be deployed in the JIRA Server. A system administrator must change the JIRA configuration to use the plugin.

For more information about Single Sign-on Integration with JIRA and Confluence, see: https://confluence.atlassian.com/display/DEV/Single+Sign-on+Integration+with+JIRA+and+Confluence

With Centrify JIRA SAML plugin deployed in JIRA Server, any unauthenticated access to JIRA resources will be redirected to Centrify Admin Portal for authentication. After that, users will be redirected back to the requested resources.

Centrify JIRA SAML plugin supports JIRA Server versions 6.x and 7.x.

If JIRA is the first application you are configuring for SSO through Privileged Access Service, read these topics before you get started:

JIRA Server SSO requirements

Before you configure the JIRA Server web application for SSO, you need the following:

  • A JIRA Server (On-Premise).

  • A system administrator account to the JIRA Server computer to deploy and configure the plugin.

Configuring JIRA Server in Admin Portal

The following steps are specific to the JIRA application and are required in order to enable SSO for JIRA. For information on optional configuration settings available in the Centrify Admin Portal, see Optional configuration settings.

Downloading the Centrify JIRA SAML plugin and signing certificate

Deploying and configuring JIRA SAML plugin in JIRA Server

This section requires a system administrator to place new files in the JIRA Server file system and modify JIRA configuration files. Note that this is a system administrator to the server hosting JIRA, not a JIRA (application) administrator.

Note:   These instructions assume:

  • JIRA on Windows.

  • JIRA installed as a Windows Service.

(Optional) Configuring SP-initiated SSO for JIRA Server

If you also want to use SP-initiated SSO, complete the steps in this section.

Note:   After you configure SP-initiated SSO, JIRA username-password login pages will not function. For more information about what this means and what your options are with SP-initiated SSO, see (Optional) Closing the back door login for SP-initiated SSO for JIRA Server.

(Optional) Closing the back door login for SP-initiated SSO for JIRA Server

If you configure SP-initiated SSO, JIRA login pages are disabled and users run the risk of being locked out of JIRA. The only way that users can sign back in with their JIRA username and password after they have been locked out is to append the parameters os_username and os_password to the end of their JIRA URL, with the URL-encoded username and password values. For example if your username is jsmith@acme.com and the password is NoPwd!, your URL would be:

https://jira.acme.com/?os_username=jsmith%40acme.com&os_password=NoPwd!

This is not secure because the password is exposed, but is the only way to use JIRA username and password to log in after SP-initiated SSO is configured. If your company wants to have SP-initiated SSO and to disable JIRA's query parameter authentication, follow the steps below.

(Optional) Disabling just-in-time user provisioning

The setting to enable or disable just-in-time user provisioning is located in your JIRA catalina.properties file, by default located in <your-atlassian-directory>\conf.

(Optional) Disabling SAML user update

SAML user update will update a JIRA user’s email address and full name to the ones specified in SAML assertion. The setting to enable or disable this feature is located in your JIRA catalina.properties file, by default located in <your-atlassian-directory>\conf.

Wait a few minutes for the service to start. The new settings that you just configured will be used after JIRA starts.

(Optional) Disabling SAML group update

SAML group update will update a JIRA user’s groups in JIRA to the ones specified in SAML assertion. The setting to enable or disable this feature is located in your JIRA catalina.properties file, by default located in <your-atlassian-directory>\conf.

For more information

JIRA Server specifications

Each SAML application is different. The following table lists features and functionality specific to JIRA Server.

Capability

Supported?

Support details

Web browser client

Yes

 

Mobile client

No

 

SAML 2.0

Yes

 

SP-initiated SSO

Yes, optional

 

IdP-initiated SSO

Yes

 

Force user login via SSO only

Yes

SP-initiated SSO: Yes, optional

IdP-initiated SSO: No

Separate administrator login
after SSO is enabled

No

 

User or Administrator lockout risk

Yes

Because SP-initiated SSO always redirects users to Centrify and disables the function of JIRA login pages, users run the risk of being locked out of JIRA. The configuration in (Optional) Configuring SP-initiated SSO for JIRA Server leaves JIRA's query parameter authentication available, so that users can use their JIRA username and password to log in to JIRA if needed.

For more information about using JIRA’s query parameter authentication to set up a back door URL for administrators and users, see (Optional) Closing the back door login for SP-initiated SSO for JIRA Server.

Automatic user provisioning

Yes

 

Multiple User Types

Yes

SSO works the same way for all admin and non-admin user types.

Self-service password

Yes

Users can reset their own passwords. Resetting another user’s password requires administrator rights.

Access restriction using a corporate IP range

Yes

You can specify an IP Range in the Admin Portal Policy page to restrict access to the application.