Social login with OIDC has arrived to SAML Single Sign-On
We have just released a new version of SAML Single Sign On that includes many advanced features of authentication with the OIDC protocol. Including the ability to authenticate with social login providers!
As you may know, OAuth2/Open ID Connect is behind every social login page where you can use your existing social profiles to log in without going through the hustle of creating a new account manually.
And that’s exactly what you can setup now for your Jira, Confluence, etc. on premise!
Here’s the list of the social login providers that we support:
- Sign in with Apple
- GitHub
- … and, of course, Atlassian!
Social login is great for public Service Desks and Wikis
Any organization that uses Confluence or Jira as a public resource that anyone should be able to access will love this one. When Confluence is an open wiki or Jira Service Management is designed to be an open resource, this feature will increase user adoption removing the friction that comes with creating that account.
The disadvantage: Anybody can log in
A huge flashy warning is due, though!
When you enable any social login for Jira, Confluence or Bitbucket, any user of the selected platforms can log into your production environment BY DEFAULT. This doesn’t mean that they will have application access – that will depend on how you handle groups like jira-users or confluence-users. But they will be inside. So be very careful of how you roll out this feature, because I could use my LinkedIn account to access your production instance. And I’m sure you don’t want that.
Is there some way to restrict access by domain? Of course, but it’s so specific to every configuration that we recommend reaching out to our support team to accomplish that together with us.
Log in with Atlassian cloud to Data Center (and Server)
This is our favorite use case by far. Many companies have hybrid Atlassian stacks, with some Jira instances on cloud, some still on Data Center. Often times, there are users with accounts on both sides. As Data Center and Server instances migrate to cloud, user accounts might be duplicated.
Using Atlassian cloud accounts to log into Server and Data Center instances removes a lot of problems that users encounter in hybrid settings and during phased migrations:
- User footprints are not linked. In general, it’s desirable for issue links, mentions, and generally every occurrence of a single user to have a unique identifier. This can have a different severity depending on how active the user is, in how many projects they are taking part, and how far along is the migration project.
- Each user has two different accounts that need to be maintained separately. Together with their passwords, account recovery policies, SSO configurations, etc.
Connecting both identities with Atlassian cloud accounts
Logging in with Atlassian cloud accounts removes the need to handle duplicated accounts and generally ensures a better usability in hybrid settings.
How can you set it up?
The implementation requires for each organization to publish an app with an Atlassian Developer account. But you won’t have to write a single line of code: just follow the guide here.
Published apps will show a screen like this:
Note: This screen will be shown every time the user logs into the on premise instance with the cloud account. Unfortunately, there is no way we can get rid of that consent screen upon login. However, keeping your session active may make that a smaller problem than it seems.
How does it work?
What happens after authentication depends on whether the user account exists already in the on premise instance.
When user accounts only exist on the cloud side
This is by far the cleanest option. When the user accounts only exists on the cloud side, then the user can be provisioned automatically upon first login with Just in Time provisioning using the 1 click button solution that our team has implemented.
This means that the Single Sign On app will take the information of the user in the OAuth2 flow to create the user on the local directory. From then, the cloud instance will work as an Identity Provider.
When user accounts already exist on both hostings
When the user accounts already exist on both hostings, things will be a bit more complex to configure at the beginning.
- You will need to match the user on the cloud instance with the user on the on premise instance. In order to do that across the user directory, a predictable pattern must be found that allows to create that match based on similarities between the attributes on both sides.
- In the best case scenario, usernames on both sides are defined as the corporate email.
- In the worst case scenario, you will need to make some attribute transformations using regular expressions or even groovy code. But that’s nothing that can be solved, possibly with the help of our support case. Note that we’re always ready to do a screenshare to fix your configuration and get you going.
Conclusion
The addition of social login options concludes our implementation of OIDC in resolution’s SAML Single Sign On. This means that you can leverage the full force of an enterprise ready app and implement virtually any thinkable configurations not only with SAML, but also with Open ID Connect.
