One of the most important developments of Atlassian Data Center SSO is that it can now provision users with SAML attributes, a method called Just in Time Provisioning.
Unfortunately for Atlassian’s paying customer, the overall feature set is still lacking for most enterprises. There are many examples.
In this article we will go over the top 10 SSO features that you won’t find natively in Data Center applications – but you will find in resolution’s SAML SSO.
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.
Provisioning features not included in Data Center SSO
User provisioning is not part of the SAML standard. However, most SSO vendors implementing the protocol use the attributes sent in the SAML response to provision users just-in-time. That’s what Atlassian does too.
While Just in Time is ok for creating users, there are better solutions out there. More and more Identity Providers have powerful APIs that can be leveraged for syncing users and information, allowing for a much more flexible flow of data.
Let’s face it: the latest version of SAML 2.0 dates back to 2005, and a technology doesn’t get any younger.
Using dated technology is not Atlassian’s only provisioning problem. Another major one is that it’s very easy to mess up groups: with every login, Atlassian takes every group in the group SAML attribute, and removes any existing groups from the local Jira or Confluence directory that are not in the response. That may just not work out for you.
However, for the sake of simplicity I’d like to focus on two major limitations of Just-in-time Provisioning in this article.
You can read more about how our provisioning works here.
1. Synchronizing User Directories
Definition of User Directory synchronization
Synchronization is the process by which the information in two databases is made identical. While each synchronization establishes consistency, databases diverge with time and need to be synchronized periodically.
Applied to user management, one-way synchronizations from the Identity Provider like Azure AD or Okta to an Atlassian application like Jira Data Center imply the following steps:
- Looking up the users in the local Jira directory to match them to the users in the IdP
- Checking matched users to identify inconsistencies
- Update matched users to remove the inconsistencies
- Creating users not found in Jira
Why is it important to synchronize user directories in Data Center applications?
The concept of storing and managing all user identities in a central resource (the Identity Provider) needs synchronizations in order to work.
Think of Sarah, who’s joining your company. When user directories are synchronized, you just need to activate Sarah on your IdP. With the next sync, Sarah will have an account in Jira and Confluence too. One single action. But if you don’t have that setup, every deactivation might become a tedious process that takes a couple of hours until Sarah has been added to every application she’s supposed to have access too.
Synchronizing users is therefore an automatic process for provisioning that propagates from the Identity Provider into connected applications.
Are there any workarounds to user synchronizations?
Yes, Just-in-Time provisioning is a workaround when you can’t synchronize your Atlassian users. In Sarah’s example, she will be able to create her Jira user herself when logging in for the first time. But the same cannot be said for a very important aspect of user provisioning: deactivating users.
2. User Deactivation
Definition of User Deactivation
Every user account has a lifetime: it will be created and it will be eventually deactivated. In identity jargon: it will be provisioned and de-provisioned. The most common reason for user deactivations are job changes, promotions, or retirements.
Why is it important to deactivate users in Data Center applications?
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 a key activity in access management and user provisioning. What the hell, it’s probably the most time-sensitive! Deactivating users can also save you money in your costly Data Center licenses. Without cleaning up, you may need to buy a higher tier based on the count of your active users without actually needing it.
Are there any workarounds to deactivating users when you can’t sync them?
Creating a connector between your Identity Provider and Jira or Confluence Data Center to synchronize both directories is the only way to automatically deactivate users.
The alternatives are to:
- manually remove them (but that’s hardly a good practice)
- write scripts with ScriptRunner to do a similar job
- or to get an app like User Deactivator to check automatically for inactive users or manually remove them in bulk.
Just-in-Time provisioning cannot deactivate users because it needs a successful login to deactivate the user. But if the user is already disabled in the Identity Provider, the SAML authentication will fail.
Technically, you can also remove the user from its Jira groups on the IdP. In this case, the login will technically succeed but the user won’t have the rights to access the application. However, note that the user will not be deactivated and will still consume licenses.
Still in doubt? Learn different approaches to deactivating users in Jira or Confluence
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.
3. Single Logout (SLO)
Definition of Single Logout
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 also closed in the Identity Provider and all connected accounts.
Why is SLO important for Data Center applications?
Users rarely close their sessions in every application when they finish working. This practice increases the attack surface for your company. SLO is a best practice supported by the SAML protocol, and allows to close those sessions centrally from a single application connected to the SSO.
Are there any workarounds to Single Logout?
Technically, if your IdP session and all the connected SP also have a timeout, you get logged out. However, IdP sessions are usually active for a long, long time, leaving your windows open.
Learn more about configuring Single Logout for your Atlassian Data Center application
4. Custom SSO urls
Definition of 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.
5. Page Templates
Definition of 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
There are also important aspects involved in the SSO process that affect both user authentication and user provisioning. Let’s name 2 that are currently absent from the Data Center native capability.
6. Multiple IdP selection method
Definition of Multiple IdP selection
Let’s be realistic: the larger the organization, the higher the number of identity providers used at the same time by different branches, divisions, or regions. Complexity is stubborn. Even after consolidation and standardization projects, having only one Identity Provider often remains as an impossible peak.
Why do Data Center customers need Multiple IdPs for their SSO?
Enterprise identity infrastructures are complex, and they may often combine multiple sources of identity. Some of them legacy, some other new cloud implementations. The ability to support multiple IdPs is therefore critical for larger Atlassian customers.
There’s another critical use case: migrations from one Identity Provider to another. If you want to migrate from AD FS to Azure AD, for example, you can simply configure both. With resolution’s SAML SSO, you can add the config for Azure AD and then switch back on forth between the old and the new config. If you encounter any errors, rolling back the migration is as easy as flipping the weights assigned to each IdP.
Are there any workarounds for the support of Multiple IdPs?
Crowd sometimes offers an alternative to using a SAML SSO implementation that supports more than one identity provider. But as of now, that means using LDAP, not SAML or any newer protocols, to connect your user directories to Atlassian products.
If you want to keep reading:
Make users select your IdP on a specific page
Redirect users to an IdP based on their email domain
Redirect based on HTTP request headers
7. Attribute mapping and transformation
Definition of 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.
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 AzureAD, 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.
Configuration Features not included in Data Center SSO
All the highlights until now are features that make single sign-on work, even in the most complex scenarios. However, it would be really hard for administrators to make the machine work without specific features that make the configuration work easier, more transparent, and more efficient.
8. Troubleshooting trackers
Definition
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. Directly in the SAML SSO app, you can:
- For problems during the initial setup, you can create a support request from the wizard and attach the tracker.
- For problems after the initial setup, you can create a tracker anytime via the System&Support section of the configuration, and then create a support request from the UI.
Alternatively, you can also download the tracker and create the support request from our Help Center.
Why are troubleshooting trackers important?
When your configuration works in the first attempt, 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.
Are there any workarounds for troubleshooting without trackers?
Yes, but it will be a blind process of testing what could be wrong. You will probably make it work, but how long will it take?
9. Exportable configuration
Definition
To export a configuration means to download the configuration as a file that can then be uploaded again into the SSO application. As a result, the Atlassian application can start functioning as a SAML Service Provider.
Why is it important to export your SAML configuration?
Our customers use this feature for testing purposes. For example, when there is a new Jira version, they delete their old testing system, recreate it with the same urls and import the configuration. Since all urls are the same, this will work as a charm.
Some advanced customers have also used it to export the configuration from a test instance and import it back to a production instance. However, production usually has a different base url, different configuration on the IdP, and different entity id, so you should only go down this road if you know exactly what you’re doing.
Together with the selection of the default IdP based on weights, the ability to export your configuration from a test instance and import it back to a production instance is a major ally for complex migration processes. In fact, it’s by far the favorite feature of customers migrating from Crowd.
Are there any workarounds for exporting configurations?
Sure. You can set it up again. Sounds like double work.
10. IdP Specific Documentation
Definition
Identity Providers have their own ways of doing things, and finding the right configuration option for and advanced setting can take time. Documentation prepared by an SSO vendor explains the step by step process on how to set up SSO to connect with that specific Identity Provider.
Why is it important to rely on specific step-by step guides for each IdP?
The risk of not having solid documentation to configure SSO with your Identity Provider is having an issue that sits in no man’s land. Since it’s not a specific problem of the Atlassian application, Atlassian support will suggest you talk to the Identity Provider. But the Identity Provider may not know the specifics of how to connect to Jira and Confluence, so they may suggest talking to Atlassian instead. It makes for an interesting game of ping pong.
Are there any workarounds for specific IdP Documentation?
Yes, navigating and comparing the Identity Provider’s documentation with Atlassian’s until the problem is figured out. It might be hard to solve or entirely inconclusive.
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.
