How you select between multiple Identity Providers matters

[#1]

Shortly before Team 21, Atlassian announced the support for multiple Identity Providers in Data Center SSO.

It’s a big, relevant announcement many enterprise customers had been waiting for. In large companies with multiple branches, mergers, acquisitions, and all sorts of convoluted infrastructures, a single IdP is unrealistic.

Unfortunately, the simultaneous configuration of multiple Identity Providers is still not ready to accommodate some important use cases that are frequently encountered during the deployment of Single Sign-On Atlassian Data Center products.

In this article we’d like to review how the new Atlassian feature works, and what are are some use cases that it still doesn’t cover.

Atlassian’s support for Multiple Identity Providers

The process for setting up additional authentication methods (IdPs) in Data Center has just two steps.

Step 1: Configure the IdP

First, it’s necessary to configure the IdP on the admin section.

To do this,

1. Go to System, click Authentication methods (left lower corner, Security section)

2. On the next screen, click the blue Add configuration button

You will then reach the configuration page. Everything you can define is included in it.

Although it’s a very simple implementation of SSO, it’s also a quite manual process.

If there’s any option you don’t find, you can refer to our comparison page where you’ll see many advanced options available on resolution’s SAML SSO Marketplace app.

Step 2: Show the IdP option in the login page

After adding more than one authentication method, the list will populate with the different IdPs. You can decide whether you want the IdP to show on the login page directly with the toggle.

And by clicking on Actions,

Again, it’s very simple process.

But there aren’t many configuration options, and you have virtually no control over the login interface and the overall user experience.

Let’s now look at popular ways to customize a multi-IdP setup to get a better feeling of the limitations.

Unsupported Use Cases

Use case #1: Implement more than 5 IdPs

In theory this is only a recommendation: Atlassian warns in their documentation against exceeding this number “for security reasons”, especially in public instances.

But adding one or two additional IdPs does not really have a security impact… unless the solution does not scale too well. Resolution customers can implement any number of IdPs, and some of them, particularly higher education institutions, set them up in the hundreds with no negative toll on security.

Use Case #2: Hide the selection page and trigger the Identity Provider automatically based on the user’s domain

Sometimes, clicking a button to trigger the relevant IdP makes sense for the user. For example, if the different options pertain to different branches or regions of the same company.

Some other times, a list of all possible options can add a lot of friction. Think, for example, of:

• managed service providers

• companies who rely on external contractors and connect their contractor’s IdP

• companies with extensive partner networks

A login page with every possible option can contain sensitive information, or simply reflect poorly on the brand. What if an employee has a hard time finding the right option in a long list of different buttons?

There are several ways to solve this problem. A solution we find quite elegant at resolution is to redirect to the relevant IdP based on the user’s email domain. Instead of a confusing list of options, the user would see something like this:

Since contractors, partners, and managed services customers all have known domains, setting up redirection rules for them is easy.

Use Case #3: Offer guidance to users on the login page

Sometimes you don’t have a long list of different roles, as was the case above.

Imagine a public instance open to both employees and customers, each with their own separate SSO processes. How do you make sure that your customers know how to interact with your Jira?

The logjn page is extremely valuable real estate where you can provide instructions, guidance and context. This is exactly what MongoDB did with their Jira login:

Use Case #4: Design a lighter interface to find your Identity Provider among hundreds

We already mentioned that many universities use our SAML SSO app. These universities work with hundreds of affiliate research institutions, and the login page needs to be customized to create a list that is usable.

Here’s the example of the University of Vienna:

Use Case #5: Set up ADSF behind a reverse proxy for your corporate network, an external IdP outside

This one’s for the geekier out there. If you have your Jira behind a reverse proxy, you can actually configure the resolution SAML SSO app to read the information from the http headers and redirect users who are browsing from your internal network to a different IdP.

Conclusion

In the last 18 months SSO has become a core ingredient of enterprise security, but it’s certainly not everybody’s bread and butter. It’s a highly technical topic that requires a very careful implementation and a lot of consideration to your specific needs.

We hope that this short guide will help you figure out how you want to connect and trigger multiple Identity providers to your Atlassian Data Center products.

The use cases included in the article are common scenarios that we have reviewed during the deployment of countless customers. If you’d like assistance figuring out the best way forward for your specific situation, you can schedule a free screensharing session through this link.