Atlassian SSO: Make an Inventory of Identity Assets (2/5)
Praecipio Consulting has partnered with our friends at resolution, an Atlassian Gold Marketplace Partner based in Germany that specializes in software development and network security, to bring you a series of blog posts about how to successfully implement single sign-on (SSO) with Atlassian tools. With more than 7 million users from 58 countries, resolution is the market leader for Atlassian Enterprise User Management Apps.
In the last article, 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 passwords 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 laying 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; but about half of the workforce uses 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 at 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. This type of products have all the chances 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 everyday 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 you shouldn’t be disclosed
Atlassian tools like Jira, Confluence or Bitbucket meet all items on the above checklist.
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 about 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 perform a 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 details in the following article 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 at least have to do it twice: once for Atlassian apps, another for your other directories.
Additionally, when 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-premises historic instances, each of them with their quirks and their settings. Often times some are Data Center, other 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 to 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 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
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, we are in the catalog)
- Some advanced features like user assignments will only be available on a per user basis
- Conditional access policies, including MFA, 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 G Suite) for their office applications. If that is your case, then choosing Google’s Cloud Identity is a natural option.
Cloud Identity Premium is included in the premium tier of Google Workspace with a cost of $25 per user, per month.
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.
For the next article of the series, we will 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.
In the fourth and last article, we’ll inspire SSO project leaders with walkthroughs and actionable examples of advanced implementations.
Stay tuned to for more tips and insights on advancing your journey towards a successful single sign-on for your Atlassian tools!