Contents

OpenID Single Sign On (SSO) into Jira

Jira OAuth/OpenID app gives the ability to enable OAuth/OpenID Single Sign On for Jira Software and Jira Service Desk. Jira Software and Jira Service Desk are compatible with all OAuth/OpenID Providers. Here we will go through a guide to configure SSO between Jira and your OAuth/OpenID Provider. By the end of this guide, users from your OAuth/OpenID Provider should be able to login and register to Jira Software and Service Desk.

You can refer the steps to configure your OpenID Provider with the Jira OAuth Client from the video or documentation given below

Prerequisites for Configuration

Before proceeding with the integration of your OAuth/OpenID Provider and Jira, ensure that the following prerequisites are met:

Ensure that Jira has been installed and configured appropriately.
Enable HTTPS on the Jira Server (optional, but recommended).
Establish admin credentials for Jira.
Obtain a valid Jira Server and Data Center License.

Download And Installation

Log into your Jira instance as an admin.
Navigate to the Settings Menu and click on Manage Apps.
Next, click on Find new apps option on the left-hand menu of the page.
Here, locate miniOrange Jira OAuth/OpenID Connect Single Sign On (SSO) plugin on Atlassian marketplace via search.
Click on Try it free to begin a new trial of the plugin with a temporary license.
When redirected to MyAtlassian, enter your information and click Generate license.
Next, click Apply license.

OAuth / OpenID Single Sign On (SSO) using OAuth/OpenID Provider, Manage apps menu

Step 1: Setup your OpenID Provider

Register an OAuth application on your Provider by configuring the Callback URL provided in the plugin. The callback URL would be {oauth_client_base_url}/plugins/servlet/oauth/callback
Collect the endpoints given below from your Provider to configure them in the plugin.

Endpoints	Use
Client ID	Identify the application.
Client Secret	Authenticate the Authorization Server.
Scope	Limit an application's access to a user's account.
Authorization Endpoint	Identify a user or obtain an authorization code.
Access Token Endpoint	Allows an application to access an API.
User Info Endpoint	Access the user profile information.
Group Endpoint (optional)	Fetch groups of a user.
Logout Endpoint (optional)	Enter the Logout endpoint of your OAuth/OpenID Provider. Leave it blank if Logout endpoint is not supported by provider.

Step 2: Setup JIRA as OAuth Client

Select Custom OpenID App from the dropdown list.
Enter the App Name, Client ID, Client Secret and Scope.

OAuth / OpenID Single Sign On (SSO), Configure Custom OpenId app

Configure all the endpoints collected from the Provider (as mentioned in the Step 1) or if you have the Metadata URL of your Provider, then click on the Fetch Info by Metadata URL button for importing configurations.

OAuth / OpenID Single Sign On (SSO), Fetch Metadata using Metadata URL

Enter the metadata URL and click on the Fetch option. All the Endpoints [like Authorize Endpoint, Access Token Endpoint, Scope and JWKS Enpoint] will be configured automatically except Client ID and Client Secret.

The format of metadata URL is {domain_name}/.well-known/openid-configuration
Here are a few examples of Providers along with their Metadata URLs.

miniOrange	https://login.xecurify.com/moas/.well-known/openid-configuration
Azure AD	https://login.microsoftonline.com/{tenant_id}/.well-known/openid-configuration
Okta	{domain_name}/.well-known/openid-configuration
Keycloak	{hostname}/auth/realms/{realm-name}/.well-known/openid-configuration

Configure the Logout Endpoint if you want users to log out from Jira along with Provider. This setting is optional. Logout URL will destroy user’s session in Jira and Provider. You can also set redirect URL here, which specifies where to redirect after Jira logout.
Click on ACR Value Check checkbox if you want to add ACR Value parameter to the authorised server request. This setting is optional. The ACR value specifies the authentication method used by the Authorization Server and is used to enable the multi-factor authentication.
Click on Nonce checkbox if you want to add the nonce parameter to authorised server request. The nonce parameter is used to validate the tokens received from the provider. Its purpose is to mitigate the replay attack.
Select the Check State Parameter and Issuer Check parameters if required by your OpenID Provider. Using state parameter, a client application can validate that the response received from the provider is not altered in between. On the other hand, the issuer check parameter verifies that the received token has been originated from the expected provider.
If your provider sends the tokens in a signed format then, configure the Public key of the provider in the text box provided. Or else you can configure the JWKS Endpoint of your OpenID Provider and the plugin will fetch the current public key of provider from that endpoint itself. This setting is optional.
Click on Save button.
Click on Test Configuration for verifying the entered details.

Step 3: User Profiles

Matching a User

a. Finding correct attributes

Go to Configure OAuth tab. Scroll down and click on Test Configuration.
You will see all the values returned by your OAuth/OpenID Provider to Jira in a table. If you don't see a value for First Name, Last Name, Email or Username, make the required settings in your OAuth/OpenID Provider to return this information.
Once you see all the values in Test Configuration, keep the window open and go to User Profile tab.

b. Setting profile attributes

In this tab, fill the values by matching the name of the attribute. For instance, if the Attribute Name in the Test Configuration window is NameID, enter NameID against Username

Setting up both Username and Email is required if you want to let users register. If you want existing users to the only login, configure the attribute using which you will match the user in Jira.

c. Matching a User

Go to User Profile tab
Select Username or Email for Login/Search Jira user account by
Enter the attribute name from OAuth/OpenID Provider which corresponds to Username or Email using Finding Correct Attributes

d. Custom Attribute Mapping

The custom attributes recieved in the OAuth/OpenID response can be configured using Configure User Properties(Custom Attributes) option.
Click Add Attributes .
Enter the attribute name( E.g. department) as User Property Key.
This option will be added in the profiles of Jira Users.
Corresponding to this key, fill the attribute value you recieved in Test Configuration window. For instance, if the Attribute Name in the Test Configuration window is Department, enter Department as Attribute.
Another attribute e.g. location can be added by reclicking on Add Attributes option.

Step 4: User Groups

Disable Group Mapping

a. Setting default group

Select the users' Default Group in the tab User Groups. If no group is mapped, users are added by default to this group.
You can enable default groups for All Users or New Users using the option.Select None if you don't want to assign any default group to SSO users, using the option Assign Default Group To.

oauth sso, oauth client, open id oauth, OAuth / OpenID Single Sign On (SSO) into Jira, Default group

b. Finding Group Attribute

Just like we found Attribute Name for User Profile attributes, we find group attribute.
Go to Configure OAuth tab. Scroll down and click on Test Configuration.
You will see all the values returned by your OAuth/OpenID Provider to Jira in a table. If you don't see value with groups, make the required settings in your OAuth Providerto return group names.
Once you see all the values in Test Configuration, keep the window open and go to User Groups tab.
Enter the Attribute Name of group against Group Attribute.
Check Disable Group Mapping option if you don't want to update groups of existing users.

c. Group Mapping

Manual group mapping: If the names of groups in Jira are different than the corresponding groups in OAuth/OpenID Provider, then you should use Manual group mapping.
On-The-Fly group mapping: If the names of groups in Jira and OAuth/OpenID Provider are same, you should use On-The-Fly group mapping.

I. Manual Group Mapping
- Check Restrict User Creation Based on Group Mapping option if you want new users to be created only if at least one of the user's OAuth/OpenID Provider groups is mapped to a group in the application.
- For mapping, first select a Jira group from the dropdown which lists all groups present in Jira and then enter the name of the OAuth/OpenID Provider group to be mapped in the textbox beside
- For example, if you want all users in 'dev' group in OAuth/OpenID Provider to be added to jira-software-users, you will need to select jira-software-users from the dropdown and enter 'dev' against jira-software-users.
- Use '+1' and '+10' buttons to add extra mapping fields.
- Use '-' button next to each mapping to delete that mapping.
II. On-The Fly Group Mapping
- Check Create New Groups option if you want new groups from OAuth/OpenID Provider to be created if not found in Jira.
- If the user is part of some group in Jira and that group is not present in the OAuth/OpenID response returned by OAuth/OpenID Provider, then the user will be removed from that group in Jira.
- If you don't want On-The-Fly group mapping to affect Jira groups which are managed locally then add those groups in Exclude Groups field.

Step 5: Sign In Settings

a. Sign In Settings

Set Enable SSO for Jira Software to allow SSO for Jira Software users.
Change the text on the SSO button on the login page using the Login Button Text option.
Set the Relay State to the URL to which the users would be redirected after login. Keep this empty to redirect users to the same page they started with.
Enable Auto-redirect to OAuth/OpenId Provider if you want to allow users to login only using OAuth/OpenId Provider. Enable backdoor for emergency.
Restrict the access of backdoor URL to limited users by using the Restrict backdoor URL access based on user groups feature.
Use Domain Restriction to allow login to only a specific set of users. You can configure multiple domains (semicolon-separated).
For example, if only 'miniorange.com' and 'gmail.com' domains are allowed then, the user test@miniorange.com and test@gmail.com will be able to log in and user test@yahoo.com will not be able to login.
Select Secure Admin Login Options to control admin access. User needs to authenticate again to access admin settings or to perform any admin operation. This helps you to add an extra level of security for admin access.

b. Service Desk SSO Settings

Set Enable SSO For ServiceDesk Customer Portal to allow SSO for Service Desk user.
Set Enable SSO Only For Agents to allow SSO only for specific set of users.
Enable Auto-redirect to Provider if you want to allow users to login to ServiceDesk only using provider and use Disable Auto Redirect to Provider to allow basic login for selective customer portals.

single sign on login, microsoft single sign on, OAuth / OpenID Single Sign On (SSO) into Jira, Service Desk Settings

c. Sign Out Settings

Set Logout URL or Logout Template to redirect users after logout action.

single sign on solutions, sso single sign on, OAuth / OpenID Single Sign On (SSO) into Jira, Sign Out Settings

d. SSO Error Settings

Set error template to redirect users to a custom error page instead of login page. Use this if you have Auto-redirect to Provider enabled.