Atlassian SSO Series Part 3: Top 6 Questions to Define Your Scope

This article is Part 3 of a five-part series on Atlassian Single Sign-On. Part 1 | Part 2

Praecipio has partnered with our friends at resolution to bring you a series of blog posts on how to successfully implement Single Sign-On (SSO) with Atlassian tools. Resolution is an Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.

In Part 1 and Part 2 of this series, we saw the main symptoms of a password disease that can be cured when applications are secured with single sign-on. We also took inventory of the core identity assets involved in an SSO implementation – including web applications, SSO connectivity, user directories, and opportunities to deploy identity providers (IdPs). 

In other words, we’ve looked at where you are. Now, it's time to look at where you want to go.  

Part of that journey involves making a final decision about the home of your user accounts once you move away from Active Directory. Will it be Okta? Azure AD? Some other vendor? 

Another part of that journey relates to extremely specific requirements that you will need to analyze to make sure that the implementation of single sign-on in Atlassian applications makes all stakeholders happy.  

In this article, we'll spell those requirements out. 

Write them down: These are the most important questions that you will need to answer in full detail before evaluating specific SSO solutions for your Atlassian applications. 

Question 1: Do your Atlassian applications support SSO out of the box?

We saw this already in the last article, but it’s worth revisiting. 

Your options depend entirely on the type of hosting of your Atlassian products, as you can see in the summary table. If you are on Server, you will plan a migration to either cloud or Data Center in the next couple of years, so that's where you should look. We won't consider SSO solutions for Server applications in this article, although the answer is easy: go to the Atlassian Marketplace. 

If you are on the Atlassian Cloud, your options can also be spelled out with 2 words: Atlassian Access. The good thing is that you need to search no more. The downside is that Access can be quite expensive, and there is no competition. 

In terms of functionality, Access has everything you could ask for. In fact, it does much more than just SSO, making it a high standard against which other solutions can be measured.  

Audit log, directory syncs, and lifecycle management are components that go beyond the basic SAML SSO functionality and towards a comprehensive Identity and Access Management framework on the Atlassian stack. 

If you're already on a Data Center license or planning a migration in the next couple of years and before Server End of Life in 2024, then you do have (or will have) SAML SSO out of the box. But the Data Center SSO offering is far away from Access. Which takes us to the next question.  

Question 2: Will Native Data Center SAML SSO be enough for you? 

Here are some facts:  

• Atlassian started providing native SSO capabilities with the SAML protocol in 2019. Originally as a free app, it’s now a preinstalled app for any Data Center customer. 
• While more functionalities are being added to the SAML-based authentication, the app is still behind. You can check their roadmap here. 

What this means is that if you have a simple need and a simple infrastructure, Data Center SAML SSO may work for you. Otherwise, you should look for a commercial alternative. In this article we will look at how common additional requirements are covered by resolution’s SAML SSO apps, with over 7 million users in 58 countries. 

Let’s have a quick overview of what the Data Center SAML SSO can do before we look at how additional requirements can be solved with resolution’s SAML SSO. 

A quick overview of Data Center SAML SSO: 

First, we'll cover the main functional requirements that Data Center will solve at a high level: 

• Authenticate users into Jira, Confluence, and Bitbucket Data Center on behalf of an Identity Provider. Spoiler alert: you will need exact username matches on both sides (see question 3). 

• Create users into the Atlassian applications during their first login, without the user being prompted to enter their Atlassian password. This is commonly called Just-in-time provisioning and happens with the information that the Identity Provider sends in the SAML response. 
  
• Update the information stored in the local Atlassian directory. This also happens during login exclusively and applies to the group memberships that define user permissions and access. 

There’s no question that these three functions alone are powerful. However, a more detailed examination is needed to ensure that you can effectively implement Data Center SSO with your current infrastructure. 

The following two questions are aimed at clearing up that part of the dilemma, before we embark on additional functional requirements. 

Question 3: Do you have different naming conventions on the identity provider and in the local Atlassian directories?

If the answer is no, then Data Center SAML SSO will accommodate you right away. You can skip to the next question. 

For example, if you are implementing Azure AD the UserPrincipalName attribute will be populated with user emails. If you also have email addresses in the Atlassian username, the match will be perfect. 

But if the answer is yes, it will not work. When the usernames don’t match immediately on either side, it will be impossible for the Data Center SAML SSO to identify which user in the Atlassian database is trying to log in. 

This will happen, for example, if instead of the example above, there are full names in the Atlassian usernames.

There are two workarounds: 

• Modifying all the usernames in your Atlassian applications to align them to the naming conventions in the IdP (Identity Provider). 
• Modifying usernames on the IdP side to align them with Atlassian (but potentially disrupting the rest of your connected applications). 

If you want a more elegant solution, you can use the user-mapping and transformation features in resolution’s SAML SSO.

In our example, there are two different strategies to create a match with resolution's SAML SSO: 

1. The UserPrincipalName is mapped with the e-mail attribute, which can then be selected as the attribute that is looked up in the Atlassian database for authenticating users. 
2. The UserPrincipalName is transformed into the username by simply stripping the email domain.

 

Note: No-code transformation options are quite varied. 

Question 4: Do you have to connect Atlassian applications to multiple identity sources? 

Enterprises rarely have a single, monolithic user directory. For historic and legacy reasons, but also because IT governance models give a lot of autonomy to geographic regions, it is most common to have a few user directories, even from different vendors. 

But even in more centralized approaches, large organizations tend to have separate user directories for different types of users, even if those directories are provided by the same cloud vendor. For example, Jira users and Jira Service Management agents could be stored in different instances of Okta. And it's even more common to separate customers and employees. 

If that is your case, then you won’t be able to use the Data Center SAML SSO app. 

On the contrary, in resolution’s apps, you can setup multiple IdPs and decide when each of them is triggered based on multiple methods: 

• The user’s decision on a selection page 
• The user’s email domain 
• Specific information included in the http request headers 
• Priority scores (by weight)

Note: Atlassian has put this feature on their short-term roadmap, but it’s unknown what will be possible with it and whether the setup will support dynamic IdP selections. 

Question 5: Do you want to centralize user management from your Identity Provider? 

In an enterprise setting, there is not a right or wrong answer to this question. It can make sense to manage users in every application locally. This usually happens when the IT team has the right expertise, and the company is small enough that change requests don't swamp the workload. 

But on a larger scale, a decentralized user management framework can become a major issue.  

What happens when user management is centralized? As employees are promoted, change departments, or are assigned to a new project, permissions can be changed directly from the Identity Provider alone. Then, they propagate immediately to all connected applications. 

The technology behind this benefit is a one-way synchronization from the IdP to the connected apps via API. Once set up, the sync will update users’ group membership at regular intervals and therefore automatically modify their access rights. 

Data Center SAML doesn’t have the ability to sync with IdPs, which exist both in Atlassian Access for cloud applications and in resolution’s SAML SSO apps. 

As you can see in the image below, resolution’s User Sync functionality provides connectors with most commercial IdPs. Connectors can then be configured so that they align to your group management practices and nomenclature. We will show a practical example of this in the next article.

Question 6: Do you want to automate user on- and offboarding? 

User syncs are vital if you want to automate user management throughout the entire lifecycle.  

Besides the satisfaction of having the power to control every detail, few administrators enjoy onboarding new users into every application. They understand it’s a job that needs to be done. They also grasp the urgency of removing access to applications when an employee leaves the company. But sometimes they might be too busy to put that task at the top of their list or to double check that every access was effectively disconnected. 

User syncs can automate the three key on and offboarding jobs: 

• When a new employee joins the company, they have immediate access to every application without even having to login for the first time. 
• When an account is deactivated on the IdP, all accesses are immediately blocked. 
• Deactivate users temporarily when they don’t access an application like Confluence for a specific time (for example, 3 months)  

For the third job, it’s even possible to create a specific connector that takes care of the automatic deactivations.

How to evaluate your answers: 

How to evaluate your answers: 

Until now we have looked at the main requirements that you must consider for your SSO implementation. It's vital to have a clear answer to all these questions before making a final decision.  

Now that you have your answers, let’s translate them into realistic options. 

 The table below summarizes your options, mapping combinations of answers with the most suitable SSO solution.  

To find which product we recommend for your use case, simply find the row that contains your answers.

As you can see, there are three main possibilities: 

• If you don’t have any of the requirements listed in questions 3 thru 6, then Data Center SAML SSO might do the job.  
• If you answered yes to question 3, question 4, or both, then it seems like resolution’s SAML SSO will be your best shot. 
• If you answered no to 3 and 4 and you still want to automate user management, then you have two alternatives:   
  • The simple alternative is to go for a complete product like resolution’s SAML SSO. This will simplify your implementation and the number of touchpoints with support experts. 
  • The cheap alternative is to implement the existing functionality in Data Center for the basic SAML, and resolution's Users and Groups Sync to automate user management. This will make you the advanced features you need to manage users and groups, but at half of the prize of the SAML SSO app. 

Now you know what’s your basic fit.  

Make sure to complete your evaluation going over all your additional requirements as instructed in the next paragraph. 

Continuing your evaluation  

We hope that our attempt at boiling down your implementation project to its essentials was successful and your scenario is realistically captured in the options above.  

But beware! These six questions leave out many details. To quickly cross-reference your feature wish list, we have published a full tour of customization options and how they compare to the Data Center defaults.  

Here’s a high-level preview. 

But if you want to learn how it works, have a look at the in-depth comparison we have prepared for you. 

What’s Next?

In this article we reviewed the native SSO capabilities of Atlassian products depending on their hosting type and doubled down on what Data Center SAML SSO can do. We then focused on three major requirements that cannot be solved with it: username mapping and transformations, multi-IdP setups, and user management automations. Finally, we took stock of the combined requirements and presented the best solutions for each of them. 

Part 4 of this series will go even deeper into how to address these requirements with resolution’s SAML Single Sign-On. We will go over the implementation project of an imaginary company that has decided to migrate out of their Active Directory into a cloud Identity Provider. We will identify their challenges, understand the value that the implementation will create for the business, and offer reproducible how-to steps to solve their case. 

Read the rest of our Atlassian SSO Series:

Part 1 | Part 2 | Part 3 (you're here!) | Part 4 | Part 5