Atlassian SSO Series Part 2: Make an Inventory of Identity Assets

This article is Part 2 of a five-part series on Atlassian Single Sign-On. Click to read Part 1.

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 of this series, we offered an overview of the most common pain points that can be felt across an enterprise when no single sign-on (SSO) solution has been implemented – or when it doesn’t extend to important corporate software like Atlassian tools.

Now you understand that without SSO, end users will stick to bad password habits. Your Help Center will be flooded with password recovery requests. And, to the despair of your security experts, your admins will keep forgetting to deactivate former employees from Jira’s internal directory. 

So, what are you going to do about it? 

Luckily for you, we are taking the grand journey to SSO before your eyes. In this article, we’ll show you the exact steps to take inventory of your existing identity resources. Once the inventory is completed, outlining the implementation project and choosing the SSO vendors should be straightforward. 

Step 1: Take inventory of web applications 

What software do your employees use? Completing an inventory of all the B2B apps used in your organization is easier said than done.  

By some accounts, employees used an average of 191 accounts in 2017, with about half of the workforce using software that was not distributed to them by their IT department. 

When setting out to complete the list, try a "good cop" approach. Interview colleagues in different departments and explain the benefits of bringing every possible application under the roof of a unique, centralized login. 

A percentage of these applications will be small SaaS vendors where the head of the department paid with a corporate credit card without requesting a budget approval for it. These types of products have the greatest risk of becoming Shadow IT: unaccounted for and unknown to the IT department until there’s a problem. 

However, for the purpose of single sign-on you should only be concerned about the apps that are relevant: 

• They’re used every day by some roles 
• They are essential to completing the employee’s job description 
• They have individual user accounts 
• They contain sensitive data about the company that shouldn’t be disclosed 

Atlassian tools like Jira, Confluence, or Bitbucket meet all the criteria from the above list.   

In case of doubt, a quick scan of data sensitivity should be enough to convince you. Bitbucket is the repository for the company’s software, Jira Software has all the plans for the product’s future features, Jira Service Management contains hundreds of customer conversations, and finally, Confluence is used to organize and disseminate documentation, strategic business plans, and links to confidential assets. 

Step 2: Check which applications support SSO  

Once you know which web applications you need to connect to your SSO solution, you should do some quick due diligence:  

• Does the application support SSO natively?  
• If yes, what protocols can be used to connect it? SAML, OAuth/OIDC, SSH, or even older ones? 
• If no, are commercial connectors available that you can rely on to do the job? 

Atlassian on-premise applications, for example, do not support SSO natively. However, there are plenty of alternatives in the Atlassian Marketplace that allow them to connect to IdPs, mainly via SAML. Resolution’s SAML SSO is the most important example. 

In the case of Data Center, there is also a free SAML SSO app by Atlassian that covers a part of the SSO specifications, including authentication and some other aspects of user management. We will go into more detail in Part 3 of this series. 

For each of the applications in your inventory, you will have to ask yourself: Where are the application’s users? Are they stored internally in the application, or are they drawn from a corporate user directory? 

In the case of Atlassian users, there are three main non-SSO options: 

Option 1. Users are stored in Microsoft’s Active Directory 

Active Directory (AD) is starting to be a legacy technology from the time of Windows 2000, but it’s still the most common starting point for a lot of companies using Windows Servers.  

When your users are stored in AD, they can be synchronized with Atlassian applications using LDAP – then they will be able to use their AD credentials for the Atlassian login. 

Pros: It’s a well-tested option that is natively supported by Atlassian applications. Besides, many customers are already using the AD FS role to integrate with cloud services like Office 365 or Salesforce via SAML. And if they haven’t yet, they can do it for free. 

Cons: LDAP is a very poor choice in remote-first approaches: it usually requires firewalls and VPNs, it scales poorly in terms of performance, and it’s not supported by many cloud Identity Providers.  

Option 2. Users are stored in Jira’s internal directory 

Jira’s internal directory can also be connected to other Atlassian products like Confluence to be used as the source of users. 

Pros: Users don’t have to be managed in other Atlassian applications. They can be centrally run from Jira’s internal directory. 

Cons: The most important disadvantage is that Atlassian applications will still be siloed against the rest of your tools. Every time you adjust access and permissions for an employee, you will have to do it at least twice: once for Atlassian apps, then again for your other directories. Additionally, if Jira is down, your entire Atlassian stack will be unavailable. 

Option 3. Users are stored in multiple directories, but centralized with Crowd 

Many enterprises have multiple on-premise historic instances, each of them with their quirks and their settings. Often some are Data Center, others are Server. Rather than merging everything, standardizing and consolidating in a mega instance, it’s simpler to just accept the complexity and add Crowd into the mix to centralize user management. 

Pros: Federating multiple Atlassian instances with Crowd is fairly simple, and you can manage users and their permissions across different directories. 

Cons: Crowd is sold as an SSO solution, but that is only true for Atlassian products. If a user logged into Crowd tries to access any non-Atlassian tool where he doesn’t have an open session, he will be prompted to login. Also, Crowd cannot handle SAML responses from an IdP.

Step 4. Analyze IdP opportunities 

You will need an Identity Provider (IdP) that can serve as the single source of truth for user identities in all your applications. 

A new IdP can be a significant financial commitment. However, sometimes you can get a top IdP vendor for free because you are already using their technology for other purposes. Let’s have a quick look at the most common scenarios. 

Have a look at resolution’s independent evaluation of the most important IdPs for more details. 

Scenario 1: Microsoft Active Directory 

This is the second time we encounter AD in this article, and it’s no coincidence.

If your administrators are already using Active Directory to manage employee access and permissions to your networks' resources, then you can have SAML-based SSO for free. Simply make use of the AD Federation Services role and start using AD FS as your Identity Provider. 

Scenario 2: Office 365 

A similar scenario to the above, but with cloud pieces of Microsoft’s game. If your company is on Office 365, then you can get Azure Active Directory for no additional cost.  

If you do so, keep in mind that the free version of AD FS has some important limitations:

• You can only use applications in the Azure app catalog (don’t worry too much, resolution is in the catalog) 
• Some advanced features like user assignments will only be available on a per user basis 
• Conditional access policies, including MFA (multi-factor authentication), will not be available at all. 

Scenario 3: GSuite 

Everyone has a Gmail account, and thousands of companies, particularly in the US, have adopted Google Workspace (formerly GSuite) for their office applications. If that is the case for your organization, then choosing Google’s Cloud Identity is simple. 

Cloud Identity Premium is included in the premium tier of Google Workspace with a cost of $25 per user, per month. 

Next Steps 

In this article we have seen how to build a comprehensive inventory of your identity assets that includes sensitive B2B applications, the user directories for your Atlassian users, and common opportunities for adding an IdP vendor from your existing stack. 

In Part 3 of this series, we'll go over the most vital questions that will help you define the scope of your SSO implementation. 

Will a simple setup be enough? Will you connect users coming from different directories? Will you automate user creation and deactivation? These are some of the considerations that will impact your project and what a successful solution will look like.

Read the rest of our Atlassian SSO Series:

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