Last Update: September 2023
In 2020, Atlassian launched Single Sign On capabilities for its Data Center applications, and it improved it with additional features like Just in Time Provisioning, or support for multiple Identity Providers.
Atlassian admins in large DC customers regularly evaluate whether native Data Center SSO meets their requirements.
This article is intended to aid them in their evaluation.
If you are already our customer, it may be useful for you to browse the full comparison with Data Center SAML based on the User Interface of our product.
User Sync and the provisioning features not included in Data Center SSO
Besides authenticating users, the information sent in SAML assertions can be used for creating user accounts as those users access the service provider (the Atlassian application) for the first time. Atlassian Data Center SSO includes that ability, known as Just in Time provisioning. And so does resolution’s SAML SSO.
However, what most customers are looking for is the ability to synchronize their user directories, which are usually hosted in cloud Identity Providers like Azure AD (now Entra), Google Identity, or Okta. User synchronization is a more efficient method for provisioning users, since it decouples the account creation from whether the user logs in or not.
Resolution’s SAML SSO has an entire component of the app dedicated to handling the synchronization of user directories which is often compared to an LDAP Sync via REST API.
Below are the top 5 features that you will be able to accomplish with User Sync – and that you won’t find anywhere in Atlassian’s native Single Sign On.
You can read more about how our provisioning works here.
1. User Deactivation
It’s impossible to disable users with Just in Time provisioning, since this method is only triggered after a successful login. The user account can be created and updated – but it can’t create users until they first login, and it can’t deactivate them.
This is a major flaw: every user account will be eventually deactivated, with the most common reason being job changes, promotions, or retirements. Simply too much work to handle manually.
Why is it important to deactivate users?
If a user is not deactivated in Jira or Confluence, they will be able to access the Atlassian applications from their next position. This makes deactivation the most time-sensitive activity in access management.
Deactivating users can also save you money. Without cleaning up, you may need to buy a higher tier based on the count of your active users without actually needing it.
How does User Sync deactivate users?
There are two main options for deactivating users with User Sync:
- Creating a specific connector to disable users who haven’t accessed the Atlassian application in a cautionary period. This connector can be scheduled to run at regular intervals, and will disable any users who haven’t logged in the last x days since the run.
- Dropping users that don’t show in the sync from the IdP. There’s a bit of a casuistic with this method. Users may not show in a sync because they’ve been dropped from the filter group or deactivated entirely; and there’s also multiple possible cleanup behaviors.
References:
Cleanup Inactive Users – User & Group Sync
Cleanup Behaviour and Scheduled Synchronization – User & Group Sync
2. Advanced Group Management
Groups govern application access, roles, and permissions. But in the IdP, groups can be global, specific to some of the applications, or anything in between. So when groups are sent into Jira, Confluence, or Bitbuckets, Atlassian admins may have to play around and do some adjustments.
Over the years, we’ve sorted many group management that were very specific. The final result is that our app allows to make virtually anything that a real customer would like to do to their group memberships.
Transformation through regular expressions? That’s our bread and butter. Conditional group memberships? You can do that with a small groovy script.
Find more information in the documentation link below or request a support session to figure out your exact use case.
References:
Group Management- and Filtering with User Sync – User & Group Sync
3. Sync Simulation and Sync Results Browser
The concept of a user directory sync is relatively simple.
But the content of a sync run is complex. And so is predicting what will happen when a sync runs, diagnosing it when it doesn’t work initially, and understanding why some users were updated while others weren’t.
User Sync used to provide a comprehensive JSON file for each sync run, containing every detail. But skimming through these files could be cumbersome for large syncs, and it was often easy to oversee tale-telling signs.
That’s why User Sync now includes two new functions that empower administrators to configure, test, and troubleshoot user sync autonomously.
The Sync Simulation allows to test a User Sync connector to see what would be the results without actually changing the local directory.
The Sync Results Browser replaces the old JSON files with a visual interface summarizing which users were updated; which users were not updated; and which updates failed.
4: Local and Server-Side Filtering
It’s not unusual for large Data Center installations to have a number of groups that is even larger than the number of users. For example: 20,000 user tiers can easily have up to 150,000 groups stored in the Identity Provider.
In these cases, most syncs will take hours to complete. Even if a required group is set as a filter from the IdP, sych that only members of those groups are filtered, the sheer amount of group memberships for those users still impacts sync velocity.
Local and Server-Side Filtering are of great help in cases like this. By selecting only the local groups of users that need to be updated, we’re seeing customers experiencing sync runs that are between 2 and 20 times faster.
References:
Required Groups – Server Side and Local Filtering – User & Group Sync
5: Profile Pictures
Many Solution Partners have customers ask them whether the profile picture can be synced from the IdP into Jira and Confluence in Data Center. For a long time, the answer to this question was a simply “I’m sorry, it can’t be done”.
And that’s still the answer if customer’s are only willing to use Atlassian’s built in SSO. However, since early 2023 User Sync added the ability to sync profile pictures from two major IdPs: Azure AD (now Entra) and GSuite.
References:
Authentication features not included in Data Center SSO
Not everything is provisioning users. Authentication, the basic SSO functionality, can also be very sophisticated. Here are three important aspects that you won’t find in the native Atlassian SSO but are an integral part of a secure and user-friendly setup.
6. Single Logout (SLO)
Single Logout (SLO) is the opposite process of a single sign-on login, and has two directions:
- When a user closes the active session in the Identity Provider, the session is also closed in Jira and Confluence
- When a user closes the active session in Jira or Confluence, it’s closes in the Identity Provider and all connected accounts.
Why is SLO important?
Users rarely close their sessions in every application when they finish working and SSO. This practice increases the attack surface for your company. SLO is a best practice supported by the SAML protocol, and allows to close those centrally from a single application connected to the SSO.
References:
Learn more about configuring Single Logout for your Atlassian Data Center application
7. Custom SSO urls
The single sign-on behavior can be customized to raise or lower the protection that it offers to specific pages in a connected web application.
For example, pages that the application shows to anonymous visitors can be secured by adding sso. And the contrary is also true: any pages can be excluded from the sso process.
Why are custom SSO urls important for Data Center security?
Resolution’s SAML SSO makes your Jira application more secure by triggering the SSO login pages that are public by default. It also offers the option to define non-sso user agents that come in handy for external applications that interact with Atlassian products. For example, when clicking a link in Outlook, Word, or Excel, often multiple SSO requests are triggered. Some customers have brought to our attention that this leads to strange problems, blocking authentication or access to the link. As a result, users can navigate links in Microsoft Office documents like emails or spreadsheets without a broken experience.
Are there any workarounds to customizing the behavior of the SSO for specific urls?
No. You will simply have to learn to live with public Jira pages, and with SSO being triggered in pages that should be public.
8. Page Templates
Page templates are layouts with specific functions in an SSO workflow that can be customized to include additional information, graphics or code so that they align properly to an organization’s brand.
For example:
- the page to select between different Identity Providers
- the page to select your organizational affiliation (very common for universities)
- the error page
- the page for redirection after logout.
Why are SSO templates important for enterprise customers?
SSO solutions are designed to have a minimal impact with users: after a successful login, a user can perfectly forget how they got to Jira.
However, there is a small number of moments where users do directly interface with the sso process. And these moments are usually critical. Number one is the login. Number two are errors. Customizing these pages to make sure that they display all relevant information and don´t confuse users should be high on any admin’s prio list.
Are there any workarounds for SSO templates?
There are, but they’re not fun. Take, for instance, the error page when an authentication fails using Atlassian’s SSO:
As it is, it doesn’t provide much of a user experience: It’s neither informative, nor entertaining.
You might be able change the content of the Atlassian SSO error page. However, it will be hard to do, it will reset every time you update Jira, and I’m not sure you will be capable of making it tell users what the hell is breaking.
Other advanced SSO features not included in Data Center SSO
Since the first time we published this article, Atlassian has released a feature that used to be a main differentiator of our app: the ability to connect Atlassian applications to multiple Identity Providers. In corporate settings, this is a very common scenario, since admins have to federate and reconcile directories that come from different countries, business units, acquisitions and mergers, or homegrown initiatives.
I could still argue that our implementation allows to configure several selection methods. While I’d rather focus on deeper differentiations that place us at an entire different level, I’ll just leave a picture here from out full comparison guide:
9. Attribute mapping and transformation
Attribute mapping is the process of defining where the information sent from the Identity Provider should be stored in the user properties of the Atlassian application.
Attribute transformation is the process of defining rules to change the values of mapped attributes in order to create an identical match in both databases, for example by stripping an email domain. Transformation is particularly important for unique identifiers like username and group name. In the case of resolution’s SAML SSO, the information can be sent either in SAML responses or, in case of UserSync, retrieved from the API of your identity provider.
Why is it important to map and transform attributes?
Mapping and transforming attributes with an SSO solution has an important implication: you can keep the nomenclature of your user directories as they are, both on the Identity Provider and on the Atlassian application. The beauty is that the transformation happens only during the SSO process but doesn’t modify the data on the identity provider, which can still coexist with its own format.
What can Atlassian SSO do?
The only mapping that Atlassian supports is for the Display Name, Email, and Groups. However, transformations and mapping expressions are not supported.
Are there any workarounds for attribute mapping and transformation?
Attributes need to be mapped and transformed, there’s no way around it. However, if you can’t transform attributes during login, you will have to make permanent transformations in one of the databases to generate exact matches. Usually, this implies changing username and group name locally in the Atlassian application.
In a standard Azure AD (now Entra), Azure will send the UserPrincipalName attribute with the user’s email as a username, for example bill.gates@microsoft.com. If Bill’s username in Jira is only Bill Gates, then you will need to transform it or send a different attribute.
10. Groovy Code
I friend at my first job in the Atlassian ecosystem told me: “it’s Groovy, so you can program anything. You can build a plane if that’s what you want!”
Well, that’s the idea: if you want to do anything fancy with the user attributes and group memberships that are coming from the IdP and you’re not happy with what you can achieve with RegEx, you always have groovy. And if you have any Scriptrunner experts in the company, they’ll very likely get the job done in no time. Not the case? That’s fine, just ask us and we’ll write the script for you!
Essentially, there are three key areas where you can implement Groovy:
- Attribute transformations. For example: you can automatically remove special characters coming from the Azure AD (now Entra) UPN so those don’t give you problems in Jira. Or if you’re doing SCIM, you can parse multiple attributes to find all the email addresses pertaining to a single user.
- Add or remove attributes and groups based on conditions. Example: Assign users to some local groups if they are member of some IdP group
- Govern access control. Example: Deny synchronization if the user seats exceed the current tier limit, or drop the user with a certain domain
Bonus! The favorite tool for Admins
The worst thing that can happen for a Jira instance is your users can’t log in. If they can’t log in, it doesn’t matter how well run your instance is; it’s still useless to them. So having tools to debug these issues and get support quickly is Vital with a capital V.
The Jira Guy
All the highlights until now are features that make single sign-on work, even in the most complex scenarios.
However, the favorite tool within the app for admins and Solution Partners doesn’t really interact with end-users: it’s the troubleshooting trackers!
A troubleshooting tracker is a downloadable file that stores the entire SAML authentication flow generated during a configuration test.
At resolution, if you can’t spot the problem with the information contained in the file, we always suggest to create a support request and attach it so we can have a look at it.
Why are troubleshooting trackers important?
When your configuration works, the tracker may not seem that important.
But when it fails, the tracker will give you every detail about what information was exchanged in the back and forth of SAML assertions between the Identity Provider and the SSO app. And for a trained eye, spotting the error will take a matter of minutes. Combine that with an excellent line of support experts that are specialized in making things work even if they are failing on the Identity Provider side of things, and you have a satisfied enterprise customer.
Conclusion
There are many other features in resolution’s SAML SSO you won’t find anywhere else. But the selection in this article should make you think twice before deciding to embark on Data Center’s native SSO, particularly if you:
- Want to automate user management and provisioning in Atlassian apps
- Have a complex identity infrastructure, including different user databases, complex affiliations, and group memberships
- Want to have full control over when SSO kicks in, so that your users’ experience is secure but not broken
- Value the option to have your configuration completed by an expert when an obscure error blocks you.
Although SSO is a transparent process for users, there are many moving pieces in a complete SSO and user management solution. Making it work with the Atlassian user databases is not straightforward.
