Missing Usecases for Atlassian Data Center OAuth SSO
Single sign-on (SSO) refers to the ability for users to login only once with a single set of credentials to get access to all corporate apps, websites, and data for which they have permission. Enterprises are readily adapting Single Sign On for their applications for greater security, improved usability and lower IT costs.
With a lot of users moving from Atlassian Server to Data Center for Atlassian applications, users now have the option to login using the in-built Data Center SSO functionality provided by Atlassian in Data Center. The in-built Data Center SSO functionality supports OAuth/OpenID SSO into the Data Center Atlassian instance using an external OAuth/OpenID Provider. Users will be able to access all Atlassian Data Center applications with the credentials of the OAuth/OpenID Provider.
miniOrange with it’s OAuth/OpenID SSO applications also supports login into Atlassian applications such as Jira, Confluence, Bitbucket, Bamboo, and Fisheye. A single set of credentials can be used to access all applications without having to enter the credentials again and again. The apps have been nurtured from its original purpose of simple Single Sign On for Atlassian to a comprehensive Single Sign On solution for Atlassian’s small, medium and big customers in over 4 years.
But you might be wondering what differentiates miniOrange’s SSO apps and the in-built SSO functionality provided by Atlassian ?
We will be looking at the 4 crucial SSO Use-Cases which are covered by the miniOrange Single Sign On applications
Use case 1: SSO for Jira Service Management (JSM/JSD)
Jira Service Management comes along with Jira Software and is widely used by many organizations as a ticketing tool. Since it is an end user interaction tool the user base is just huge and along with a big user set the responsibility of handling and managing is tough.
Here comes miniOrange solution with great user experience for Jira Service Management. The best thing about miniOrange solution is you don’t have to do any additional setting if you have an OAuth/OpenID Provider which is common for Jira Software and Service Management. The same settings will work out of the box for Jira and Service Management.
You can enable and disable Jira Service Management Single Sign On (SSO) using a simple toggle button.
If you are wondering about how user experience would be if you want to use multiple identity sources or have dedicated identity sources for Jira Software and Service Management login then you don’t need to worry about it, we already have a provision for that.
Multiple OAuth/OpenID Providers
Here you can configure dedicated Providers for Jira Software and Jira Service Management and user roles and permissions will be managed by that particular OAuth/OpenID Provider. This integration will provide you a seamless and smooth login experience and it will be easy to manage and maintain users.
Login for Service Management Agents
This ensures that only Jira Service Management agents are allowed to login into the Data Center through SSO only if they belong to the roles or groups specified under the Jira Service Management settings. Other users will be asked to login with their local Jira credentials.
Use Case 2: Close session from all the connected applications using a single click
This can be achieved with Single Logout (SLO) functionality and is supported by OAuth/OpenID SSO protocol.
Now, what is Single Logout? Let’s consider the ideal case where Jira and Confluence Data Center are connected with the OAuth/OpenID Provider. So
- when you log out from Jira you get logged out from OAuth/OpenID Provider and the other applications connected to the Provider such as Confluence.
- when you log out from OAuth/OpenID Provider you get logged out from Jira and Confluence.
Ease of Single Logout
Generally, we don’t have a habit of logging out from each application if we are working on multiple applications. It is simply boring and very annoying to do the same thing daily and get logged out from the N number of sessions.
In Single Logout, all applications which are connected to the Provider get logout automatically if one logout operation is performed for any of the applications.
What if you go with Native Data Center SSO where Single Logout is not available?
If we don’t have an option of Single Logout then we would need to always depend on the Jira or Confluence and OAuth/OIDC Provider session timeout. Generally, the sessions for these Atlassian applications (Jira, Confluence ) are very long and they are active for a long time. If not logged out explicitly the system is more vulnerable to cyber-attacks.
Use case 3: Manage user permissions in Jira Data Center
What are User permissions?
In any Atlassian applications like Jira or Confluence, you need to manage which user will access what project or space and the level of access they have. That is user permission management, and it's mainly done by assigning appropriate groups to the user.
Administrator can associate particular access rights to the groups, which in turn get applied to the users who belong to that group.
Atlassian SSO and Provisioning the user groups
In a situation without SSO, the administrator will have to manage groups for each of the applications. By introducing SSO into the picture, the administrator can manage groups in OAuth/OpenID Provider and sync or provision that in SSO connected Atlassian applications.
In realistic cases with different departments handling different applications, the administrators may not be responsible for managing the groups in both OAuth/OpenID Provider and Atlassian applications and would manage all or some of the groups locally. This has been taken care of by miniOrange SSO applications.
With miniOrange’s SSO plugin you can choose to sync all groups or selective groups from OAuth/OpenID Provider based on your requirements.
A few cases which are supported -
- Some groups are present in OAuth/OIDC Provider and the rest are locally created to manage users.
- All local groups are different than OAuth/OIDC Provider.
- All or some groups in OAuth/OIDC Provider are present in local Atlassian application but with different name.
- All groups in OAuth/OIDC Provider are present in local Atlassian application with the same name.
With Atlassian Data Center’s in-built SSO or native SSO, you can sync OAuth/OIDC Provider groups to local groups with the same names but all other cases will not be fulfilled. You will not be able to manage OAuth/OpenID Provider groups along with local groups which might cause permission issues.
When using miniOrange SSO for Data Center, you get the flexibility to include local groups and configure a few important groups as Default groups. These groups will automatically get assigned to the user after Single Sign On (SSO).
When Jira is synced with an external directory, and permissions for directory is Read Only with Local Groups, you can simply assign local Jira groups to the user and manage your user permissions within Jira itself while turning on SSO for all your users.
Use case 4: Do not show Jira/Confluence Login page for Authentication
Once the Single Sign On integration for Atlassian Jira Data Center is successful, what will be the next step? Seamless and good User Login Experience? Yes, ofcourse!
For easy and convenient login, you can simply separate out Data Center local user and OAuth/OpenID Provider user login page. Local users can login via Jira Data Center Login page and others can ask to authenticate through SSO, who will get to see the OAuth/OIDC Provider login page instead of the default one. It also involves a security threat, to letting non-admin users access the default login page, if only admin users are meant to access it.
Atlassian Data Center does provide the option to enforce SSO on users. So do miniOrange's OAuth/OpenID SSO too. Then you might be wondering what difference it will make to use miniOrange's OAuth/OpenID SSO ?
Let’s say, unfortunately your OAuth/OIDC Provider goes down or you have messed up something which causes an error while performing Atlassian SSO, then what? Your users will be locked out and won't be able to access their own account and data. And things will not stop here, even you being the admin won't be able to access the default login page, to get into the Jira/Confluence. You wouldn’t have any option but raising a support ticket to the Atlassian and keep waiting. And then you'll be thinking if by any chance you could bypass the SSO for the time being.
Emergency URL for Jira/Confluence to bypass Data Center SSO!
That's where the miniOrange OAuth/OpenID SSO comes up with a useful feature called Backdoor URL or more specifically Emergency URL. It lets you access the Jira/Confluence's default login page even if SSO is enforced for all the users.
Basically it is a URL that enables you to bypass the Single Sign On (SSO), and use the local credentials. Also, it is configurable so admin gets to decide what it should be. Thinking about more security? We got you! For that you can enable group restriction upon the Emergency URL, so that only users belonging to particular groups will be able to access the default login page.