Connecting more than one identity provider
In 2020, to further develop user authentication features, Atlassian introduced the ability to connect more than one identity provider to a server/Data Center product.
This feature was aimed at the largest enterprises who required more than one identity source on a daily basis.
"For our employees we're starting to use Azure AD for SSO/SAML authentication... Is it possible to have multiple IdPs for different purposes (agents and customers)?"
- Content comparison company
I was a part of the team tasked with delivering more value to Data Center products, and one of the projects we looked into was connecting multiple IdPs.
note: because of my non-disclosure agreement, I have omitted confidential information in this case study, including exact data and some elements of the design.
My role
I was responsible for the design process and deliverables, including gathering insights from the customers, conducting workshops with product teams and producing detailed user flows.
I worked with a Product Manager and feature lead to explore problem space and work around technical constraints.
Challenges
Existing solutions (SAML and OpenID Connect implementations) allowed the admin to configure just one identity provider (IdP). This was not flexible enough for our largest customers; they needed to be able to authenticate their users against different IdPs and provide federated access to resources from Atlassian products.
One of the use cases for two different identity providers: users authenticating with IdP1 can only access Jira Service Management (JSM) as customers, while those authenticating with IdP2 can access JSM as agents and can login to company Jira Software.
We had to build the feature within the constraints of both the existing implementation and market standards. What is more, we were building for two distinct personas: the admin and the end-user.
Additional challenge was that we had to switch to remote work in the middle of the project due to Covid-19, which meant I had to use digital whiteboards for team workshops and alignment.
Assumptions:
The user may not know which IdP they have to authenticate with to access a product.
Admins may want to define up-front who can identify with which IdP.
Personas
Will, the system admin
Will is governing identity for Acme. They've been using Okta as their IdP, however they have recently acquired another organization, CHOAM. The priority is for CHOAM employees to be able to log into Acme systems, especially Confluence, however Will wouldn't like to change the whole setup and infrastructure. CHOAM is using Ping Identity to authorize their users and Acme would like to keep using that IdP as well.
Problem statement:
As an admin responsible for user identity, I need to give my users the ability to authenticate with the right identity provider, so I can assign the correct access and privileges to different groups of users.
Alana, end user
Alana has been working at Acme for two years now; she has her rituals: morning coffee, checking email and Slack, then starting work. She's governed by her routines and really distrusts any changes from the usual flow.
Problem statement:
As an end user of Atlassian products, I need to log in to a product of my choice so I could access content that I need to see, without unnecessary steps.
Challenges, part 2
Even if the admin flow was more complex, it was the end user part of the journey that proved challenging.
There exists two standards on the market regarding end-user experience: automatic redirect to the right IdP, based on pre-defined criteria, or manual choice on the part of the user.
I believed that the better experience would be automatic redirect, as the user has lower chance of error. Unfortunately, this solution proved to be very demanding on the technical side and I had to compromise.
In the end, I opted for customized login gateway: the admin would have to provide a meaningful text that would appear on the button to help guide the user to the right IdP. This design was aligned with the way login pages worked in Atlassian and allowed for addition of Customer Portal link (entry point to Atlassian Help Desk, Jira Service Management).
Implementation
The feature was implemented at the start od 2021 and included both admin and end-user experience. The admin could add multiple configurations, test them and include them on the login gateway, while the end user would see a login landing page, where they could choose how they want to proceed.
The default authentication method, user name + password, was kept as a fail-safe. If all other authentication methods were to be disabled, basic login form would become available to prevent users from being locked out of their systems.
Impact
As with all features released in server / Data Center products, the data comes late as customers upgrade to new versions of the products. We're still waiting for meaningful insights, but we can see an increase in the Single-Sign-on functionality which could be an indicator of growing multiple IdPs usage.
The number of SAML configurations for Jira Service Management grew by 52% since the feature release and we're expecting the number to grow as the feature is adopted.