Over the last two months, our Co-Founder and Co-CEO Christian Reichert went on a virtual tour globally to discuss the differences and similarities between our SAML Single Sign On apps and Atlassian’s native implementation for Data Center customers with the goal of solving a very basic doubt: why should anyone pay for a feature they already get with their license?

If you missed it, you can check this open session that we streamed over social media or this detailed comparison page.

How did Chris survive the nearly two dozen sessions? We honestly don’t know. There are different versions of the story, but they all have something in common: it’s easier when it’s more interactive. Our partners asked all types of questions, from the SAML basics to business strategy questions, down to the most intricate details of a customer case. We’re selecting the best questions and answers so you don’t miss on all the fun.

If you’re the admin of Jira Data Center or Confluence Data Center, or a consultant with customers that need user provisioning in addition to their sso, keep reading! In this article you may learn a thing or two.

Single sign-on used to be a nice to have. In 2021, it’s become mission critical, especially for large organizations.

Strategy questions

1. I’m moving from Server to Data Center, so I don’t need the resolution SAML SSO app anymore. Am I missing something?

Well, we like to say that you get what you pay for. The Data Center SAML SSO is a very simple implementation that requires manual work and doesn’t come with a lot of documentation. That’s a recipe for risk.

Sometimes, it’s just hard to make it work from the very beginning: will you be able to collect all the information to configure SSO in a reasonable time? Will you be able to debug an authentication problem? And for how long can you afford to investigate the problem while your users can’t access Jira? Will you discover hidden requirements or limitations that block you? And will you get quality help when you really need it? Even when your problem is in the Identity Provider and not on the Atlassian side?

The reason we have over 8,000 customers using our product, many of which are large corporations with very skilled administrators, is that we guarantee a successful implementation that effectively removes passwords without adding any headaches. That doesn’t mean only a rich set of features, but also a dedicated and responsive support team. Our marketplace reviews show a consistent experience of experts that go way and beyond to make sure that customers get everything they need, and in that sense we’re deployment partners.

2. So when is Data Center SSO good enough for me?

Of course, there are many customers who don’t need anything special and are happy with the Data Center SSO. Usually they have some things in common, for example:

• Their users are stored in Active Directory with an easy configuration
• They have no particular security requirements, like encrypting SAML responses or Single Logout
• They are ok with setting an an alarm to remind them when the IdP certificate is about to expire and needs to be renewed.

If your company has a simple setup and only wants to authenticate users, not create them, then Data Center can be safe bet. As soon as you start creating users, there usually are configuration details that are too specific for the Atlassian implementation.

3. How do you make sure that you stay ahead of Atlassian’s SSO?

We’re constantly working on shipping additional improvements based on the feedback that we get from customers and partners. In the last weeks, for example:

• We shipped an experimental connector to provision users with SCIM 2.0
• Included a new integration with Linchpin User Profiles, so that their customers can now use IdPs as a source in addition to LDAP
• Repackaged User Sync so that it gives us the ability to create new connectors using groovy code. This means that we can now respond better and faster to customers who need to integrate directories from third party cloud applications.

And our roadmap is still quite full of new projects and exciting developments. Just to tease out a couple of things we’re working on right now:

• An additional integration with Communardo User Profiles is on the works
• We will be including OpenID Connect / OIDC capabilities based on OAuth 2.0. We already have an OIDC authentication app, but this step will ensure that companies using OIDC can enjoy the same level of configuration and flexibility as any other customer.

4. What’s the favorite feature for partners?

Customers and partners have told us that the authentication trackers alone are worth paying for the app. Here’s what the Jira Guy says about this feature:

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.

Authentication trackers do what their name says. They track every authentication event, including all the information exchanged in the SAML protocol between the IdP and the Atlassian application. When an authentication fails, you can understand the errors with the tracker. For example, trackers are great for spotting cases in which users are missing an attribute and nothing else tells the users that they are missing it.

And what if you don’t know how to read them? Easy. Each tracker comes with a button that creates a support case and attaches the tracker itself to our Jira Service Management. That way we can read it for you and show you how to fix it.

But stop reading and watch it in action.

Technical questions

5. I already have my users synced with LDAP. Why would I want to use your app?

LDAP (short for Lightweight Directory Access protocol) and SAML are not mutually exclusive, rather complement each other: LDAP connects accounts from on-premise applications and SAML is a language that extends user identities to web applications.

This one depends a lot on your installation. Many companies have some directories on Active Directory, but need to connect to cloud Identity Providers to authenticate for example customers. Or it may happen that you are planning to host your Jira on AWS. In that case, the sync to your private network LDAP will break and you could look at replacing it with a REST API synchronization like User Sync.

6. How are you able to include Groovy without compromising security?

We love this question. It’s true that groovy code is used for scripting and scripts are perfect hacker material which can be used maliciously. But we have some straightforward control measures.

First, we don’t allow administrators to start writing their groovy scripts from the get go. Groovy code can be used for two very specific functions: transforming user attributes that come from the Identity Provider before they are stored in the Atlassian directories; and creating a custom connector to synchronize cloud user directories, or even a custom connector to LDAP. This means that we can restrict the scope of what’s possible, while still giving freedom to do anything that is needed in order to solve those specific aspects.

Second, we have included additional measures to strengthen security. Even within the defined scope, only some Groovy expressions are possible and you will only be allowed to use the APIs etc. that are really needed.

Third, our reasonable expectation is that customers won’t actually write groovy code. We will be the ones writing the groovy scrips most of the time once we understand the requirements of support cases coming in, and when less labor-intensive options are exhausted.

Of course, some customers may in the end do the maintenance of their scripting, and perhaps even write some of their own. But in practice, only expert consultants and the resolution team will have their hands on groovy.

7. What are the risks involved when a SAML response is signed but not encrypted? Is it not enough to go over https?

When the IdP responds to an authentication request sent by a Service Provider, it can send a lot of information in the SAML attributes: the most common are username, group memberships, first and last name. But many organizations send more. While there’s not a tremendous risk in that information leaking per se, it could be the starting point for some social engineering attacks. This could happen if an attacker has gained power over your browser. And that’s why many security divisions require those SAML assertions to be encrypted.

However, the number one petition of security divisions remains that the SAML authentication request is signed, so that only trusted applications can initiate a SAML request.

Neither signed authentication requests nor encrypted SAML messages are supported by Atlassian Data Center SSO. We support both.

8. I have 3,000 users on a spreadsheet that need their usernames changed. Can I just upload them to User Sync?

We do have a connector for Excel that will take the users on a spreadsheet and update their attributes with the data that you upload from it. However, you should only do this on your own if you know what you’re doing.

What we always suggest is that you schedule a support call with us so that we have a look at your spreadsheet, make sure that it has the right formatting, and that the consequences of the upload are what you actually want to do.

9. Where do you store the attributes that are not supported in the Jira profile?

Right now there are two options for storing user attributes in Jira that are beyond the limited scope of the Jira profile.

The first one is to save them as User Properties. The second is to save them as Crowd attributes (which should not be confused with Crowd, the Atlassian unified directory). These properties and attributes cannot be seen by other users, but they can be seen by admins, and they can also be used in workflows and automations, and also by apps like Scriptrunner or Jira Misc Workflow Extension. We have customers that use this kind of flow for automatically maintaining their approvals with the right managers.

In third place there are integration options. If you have Linchpin in your Confluence, you can select IdP as a source and send data with our app. Very soon we’ll extend this option to Communardo User Profiles for Jira and Confluence.

10. What are the limits for sending groups?

The limits for sending groups are not on our app or Atlassian’s. They’re usually on the Identity Provider. Azure AD (now called Entra) is a very good example.

The classic limitation with sending groups from Azure AD (Entra) is that it doesn’t send group names in the SAML response, only numeric IDs. This means that when you’re sending dozens of groups, it becomes really difficult to handle them in the Atlassian directory.

Another limitation is the maximum number of groups that can be sent. 150 may seem like a reasonable limit, but at a certain scale it’s not that much. Many corporations have more than 150 different teams or departments.

All these limitations disappear when you sync the groups instead of using Just in Time provisioning. When you move from SAML to API calls, there’s simply no limitations to how much information you can send.

License Management Questions

11. Do you have any surprises or new applications?

Yes, we have just released a new version of our User Deactivator apps that includes a very interesting feature: license optimization. Here’s how it works:

As you can see, what it does is basically identify which users are not currently using the application and remove them from the group that consumes licenses, without deactivating them. This dynamic model is designed to make it easier for companies to stay within their current license tier, even at larger scales.

We also have a new app on the Atlassian Marketplace that allows to handle user authentication seamlessly with an AWS Load Balancer. It’s a very simple installation, but if you’re hosting Atlassian apps in AWS, it’s a very interesting option to connect to the Identity Provider with even more security.

12. How is that different from deactivating users with User Sync?

Well, it’s actually very different.

User Sync (both the standalone app and the SAML SSO module) has different methods to disable users who haven’t logged in and to clean up users who’re no longer on the Identity Provider.

What these methods are designed to do is to remove access from users who should not enter the Atlassian application any longer, either because they’re not part of the organization anymore, because they have changed position, or because they just don’t need to use Atlassian applications every week. The key here is that you deactivate or clean them up because they will neither request nor need access to the application in the foreseeable future.

In the second case, the License Optimizer does not change access for any users. All users handled by the optimizer will remain active and will still be able to log in just like they were before. What happens is that they only consume a license while they’re using the application.

What both apps have in common is that they track inactivity time. But while User Sync deactivates users, the license optimizer simply allows to “lend” the license to someone who actually needs it.

To put it in a time perspective, User Sync works in increments of weeks, days at most. The License optimizer works in increments of hours or minutes.

Conclusion

Single Sign-On used to be a nice-to-have feature for any company who wanted to rid its users from cumbersome account management and email conversations to retrieve a lost password. In 2021, it’s become mission critical and the number one strategy, together with the adoption of password managers, to protect credentials and systems while lowering IT costs. Also, SSO shifts the burden off people to the solution itself.

Enterprise identity management must be capable of being adaptative and embrace complexity. If you need to have a closer look at the functionality of our products to better understand how it can fit into your current resources, feel free to request a support session to explore your sso needs.