SSO in Jira and Confluence with OpenID Connect

How to authenticate a user in the Atlassian Ecosystem


OpenID Connect, OIDC for short, is one of the protocols Kantega Single Sign-on implements to provide single sign-on functionality for Jira, Confluence, Bitbucket and Bamboo. Through OpenID Connect, it is possible to delegate authentication of users from the Atlassian application itself to an Identity Provider like Microsoft Azure Active Directory. Kantega SSO acts as the middle-man between the Atlassian Ecosystem and any given Identity Provider, so that users can employ the same digital identity for Atlassian as they do for all their work applications:

Role of Kantega SSO in the Atlassian Ecosystem


Authentication process

Imagine your company needs to set up single-sign-on for Jira. Four entities are involved in this scenario:

  • User: The person attempting to log in.
  • Jira: The application, which the user is logging in to.
  • Azure Active Directory: A database of users that is part of Microsoft's cloud.
  • Kantega Single Sign-on: An integration application installed in Jira, which facilitates the communication between the other entities.

The process then goes as follows (Please refer to the numbers in the illustrations to follow each step):

KSSO-OIDC-azure-flow-steps-1-4.drawio(1)

Step 1

A user wants to access something in Jira and browses to the company's Jira.

Step 2

Kantega Single Sign-on detects the login-process, and sends the user to Azure Active Directory for authentication.

1-jira-login-redirect

Step 3

The user provides Azure Active Directory with their username, password, and optionally a code from SMS or verifying the prompt in an authenticator app.

2-azure-ad-signin

Step 4

Next, Azure Active Directory sends the user back to Jira with a permission slip (called Authorization Code) where Kantega Single Sign-on now acts as a doorkeeper. But we're not quite done yet. First, Kantega SSO needs to obtain some more information by communicating directly with Azure Active Directory using the permission slip.

The permission slip is needed, because Kantega Single Sign-on can not trust a malicious user to truthfully relay the result of authenticating with Azure Active Directory. Instead, the "permission slip" lets Kantega Single Sign-on ask Azure Active Directory directly about the particulars of a given login-attempt.

KSSO-OIDC-azure-steps-5-6.drawio

Step 5

Using the permission slip, Kantega Single Sign-on can ask Azure Active Directory directly about the particulars of a given login-attempt. The purpose is two-fold: First, it is now able to prevent a malicious user from relaying a false authorization with Azure Active Directory. Second, it can access information about the authorization previously performed by the user at Azure Active Directory. Was it successful? Who authenticated? What is their name and email? Do they have any special roles? And so on.

Step 6

Kantega Single Sign-on received the information and relays it back to Jira. In the case of a successful authentication, Kantega Single Sign-on tells Jira to give the user access to start browsing. Kantega Single Sign-on can also be configured to update the user's profile, or even create a new profile for first-time users in an approved organization.

Now the user is successfully authenticated!

Summary

Any kind of single sign-on is already a significant advantage over native login in terms of security and user experience. When compared to other protocols for single sign-on, OpenID Connect has achieved a high degree of specification-compliance throughout the industry, meaning much of its functionality can be used without a vast arsenal of vendor-specific band-aids.

In short, OpenID Connect is a great alternative when you need to connect your on-premise Atlassian application to a user directory, both in the cloud and on your company network. Kantega SSO Enterprise is available for Data Center and Server for Jira, Confluence, Bitbucket and Bamboo.

Similar posts