Co-CEO of re:solution GmbH
Why pay for
Data Center SSO?
A conversation with
resolution's CEO
Why pay for Data Center SSO?
A conversation with resolution's CEO
Single sign-on used to be a nice to have, a luxury feature for those who couldn’t tolerate handling passwords for their cloud applications. In 2021, it’s become mission critical, especially for large organizations.
Few people are better witnesses to this process than Christian Reichert, who has built a multi-million dollar business based on a plugin he coded for his personal use almost ten years ago!
We were the first Single Sign-On solution in the Atlassian Marketplace and that helped us stay top of mind. I can't stress how important that is.
QAs a newcomer into the Atlassian on-premise space, my first impression is that Data Center applications already offer Single Sign-On, so it feels absurd to look for a different plugin. Would I be very wrong if I didn’t go into an evaluation of your SAML SSO app?
Christian Reichert: I think that in a lot of cases you would be making an important mistake and rushing to judgment. I 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.
I don't think that Atlassian's SSO team is much larger than ours. And we're focused on delivering what enterprise customers want.
QI see. You speak about a lot of cases, but I guess that in some others Data Center SSO could be good enough for me. When would that be?
Christian Reichert: Well, there’s no simple answer to that. Casuistics are quite complex, and what we do is make sure that our plugin fits perfectly regardless of any infrastructural quirks in the customer stack.
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.
QThis is a very touch race between a large corporation and a small team. How do you make sure that you stay ahead of Atlassian’s SSO?
Christian Reichert: Well, it’s about focus and specialization. I don’t think that Atlassian’s SSO team is really much larger than ours. 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 just included 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
- We shipped an experimental connector to provision users with SCIM 2.0
- Included new integrations with Linchpin User Profiles and Communardo User Profiles for Confluence and Jira. 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!
I don't think that Atlassian's SSO team is much larger than ours. And we're focused on delivering what enterprise customers want.
QWhat’s been the key to success for resolution? Did you rely on great marketing early on, big advertising budgets?
Christian Reichert: We were the first to market. I can’t stress enough how important that is, being timely and sizing a window of opportunity. We were the first Single Sign-On solution in the Atlassian Marketplace and that helped us stay top of mind. And besides that, our growth strategy was to work a lot with partners, to make sure that they understood the tool and were trained and knew how to get it to solve complicated use cases.
QAnd what’s the favorite feature
for partners?
Christian Reichert: Customers and partners have told us that the authentication trackers alone are worth paying for the app. It makes sense, because trackers say whether the implementation has worked or not, and if it hasn’t, then they still need to work on it and the same tracker tells them where they should start looking.
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.
There’s a small video I did to cover the grounds, I’m sure the marketing guys can include it in the interview.
QOk, so imagine I’m a company and I already have my users synced with a classic LDAP. Why would I want to use your app?
Christian Reichert: LDAP and SAML are not mutually exclusive, rather complement each other: LDAP connects accounts from on-premise applications and SAML 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.
QYou use Groovy modules in the product to create custom functionality. How are you able to do that without compromising security?
Christian Reichert: 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. 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, I honestly expect that customers will never 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 other solutions are not possible.
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.
Honestly, I don't expect any customer to write Groovy in our app. But the Groovy module will make my team and my partner's life a lot easier.
QI’ve seen companies that have 3,000 users on a spreadsheet that need their usernames changed. Can you help this guys or are they doomed to fail?
Christian Reichert: In User Sync, which is both a standalone product and a module of the SAML SSO app, 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 upload will do what you actually want it to do.
QThe Jira profile doesn’t have a lot of information about users. What can customers do to store information that is not supported?
Christian Reichert: Right now there are two options for storing user attributes in Jira other than in the Jira profile, which is quite limited as you say.
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 or Communardo User Profiles for Jira or Confluence, then you can select IdP as a source and send data with our app.
QGroups are a cornerstone of how admins control access to applications. Are there any limitations to how you can handle them with the app?
The limits for sending groups are not on our app or Atlassian’s. They’re usually on the Identity Provider. Azure AD is a very good example.
The classic limitation with sending groups from Azure AD 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 via API 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.
QYou’ve made some noise earlier this year with your call to support Server customers locked in their user tiers. What is that about?
Christian Reichert: Well, we believe that customers who have decided that they can’t or won’t move away from Server should still have a functional instance. And this means that you need to have the ability to give access to every new user.
When you can’t upgrade, then some of the new users will not be onboarded. As simple as that.
We have a small tool called User Deactivator that can optimize license consumption. The idea is that you can let new users in deactivating or temporarily removing other folks.
We made a small video to show how the license optimization feature 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.
QThat’s really interesting. Hopefully you can help many customers while they get ready to migrate.
Christian Reichert: That’s the idea. We fully understand that customers will have to make their mind and migrate to either Data Center or Cloud. But it makes sense to me to give tools so that they can own their own timing.
