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.

Many Atlassian application users have switched from Atlassian Server to the Data Center, where they can now use the built-in Data Center SSO functionality provided by Atlassian. With an external OAuth/OpenID provider, the built-in Data Center SSO functionality supports OAuth/OpenID SSO into the Atlassian instance. The OAuth/OpenID Provider credentials will allow users to access all Atlassian Data Center applications.

miniOrange's OAuth/OpenID SSO applications allow login into Atlassian applications them being Jira, Confluence, Bitbucket, Bamboo, and Fisheye. All applications can be accessed with a single set of credentials, eliminating the need to repeatedly enter the credentials. Since its inception as a simple Single Sign On solution for Atlassian, the apps have evolved into a comprehensive Single Sign On solution for Atlassian's small, medium and large customers.

However, you may be wondering how miniOrange's SSO apps differ from Atlassian's built-in SSO functionality?

We will be looking at the10 crucial SSO Use-Cases which are covered by the miniOrange Single Sign On applications.

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.

This can be achieved with your OIDC Provider’s Logout Endpoint which is supported by OpenID SSO protocol.

Now, how exactly does Logout Endpoint work? Let’s consider the ideal case where Jira and Confluence Data Center are connected with the OpenID Provider. So

when you log out from OpenID Provider you get logged out from Jira and Confluence and/or connected applications.

Ease of Logout Endpoint

Generally, we don’t have a habit of logging out from each application if we are working on multiple applications. It is simply inconvenient to do the same thing daily and get logged out from the N number of sessions.

Using Logout Endpoint, 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 Logout Endpoint isn’t able?

If we don’t have a way to Logout of all connected apps to our OIDC Provider then we would need to always depend on the Jira or Confluence and/or any of the connected service based application’s 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.

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.

Administrators 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 -

1. Some groups are present in OAuth/OIDC Provider and the rest are locally created to manage users
2. All local groups are different than OAuth/OIDC Provider
3. All or some groups in OAuth/OIDC Provider are present in local Atlassian application but with different name
4. 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).

Directory Permissions

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.

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 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.

Enterprise organization infrastructure is complex and there is always a big problem of how to manage internal and external user login in the Data Center. Sometimes user identities are stored in multiple Identity Providers or sometimes multiple directories are under the same Identity Provider.

So how to solve this critical problem and make sure of a smooth user login experience? Well, it is not that difficult when it comes to the miniOrange OAuth Single Sign-On (SSO) plugin.

By default the OAuth plugin allows for all domains to reach to the login page since no domains are specified. You just have to define certain allowed domain rules on the user set for domain names which should be allowed for logging in. Depending on the domain they access Jira from, they could be redirected to their respective IDPs or URL’s.

The plugin can be configured for a single, or multiple different domains, these can be mapped for internal and external users.

In short, you just have to define differentiating domains for users and the rest will be handled by the miniOrange OAuth SSO plugin.

In case we are not able to come up with any of the factors then there is an option to map the Identity Provider for the default login page and let the user login.

Let’s consider an example of Domain based mapping for Internal users and External users.

There exist several OAuth Providers, some established some custom. Each providing varied degree of permissions to access any users personal data for the services to be used. Having to chose one that works well with your OAuth client can be tricky, especially providing a distinct level of access.

So how to solve this critical problem and make sure of a smooth user login experience? Well, it is not that difficult when it comes to the miniOrange OAuth plugin.

You just have to define certain rules on the user set or you could be already using those rules for managing internal users and external users.

Consider a scenario where a custom IDP requires additional parameters, such as phone details. So how do you go about serving to this OAuth providers' requirements?

In such cases would it not be convenient to be able to add a new request parameter? One that caters to the OAuth providers' specifications. That’s precisely what miniOrange OAuth plugin can help you achieve with ease!

You can add these parameters in Authorization Request Parameters during initial configuration of your IDP or simply head over to Configure OAuth tab and hit Edit. Select the appropriate parameter amongst :

1. ACR Values
2. State Parameters
3. Nonce parameters

Or simply select Add More Parameters as required and you should be good to go.

Having miniOrange OAuth plugin by you, having to deal with multiple providers and their requirements is pliable and hassle free!

Suppose an insurance based company needs additional attributes and wants to provision employee information such as Department, manager, etc. in Atlassian applications with SSO. Being able to configure additional User Profile Attributes can help provide this necessary information and without discrepancies.

In such circumstances, it would be exceptionally convenient and advantageous to be able to have functionality such as Customization of User Profiles. And evermore beneficial to be able to configure these functionalities as per administrator’s requirements.

User Profile allows you to map your OAuth Provider profile attributes to your Jira user attributes. Jira OAuth Plugin allows to Configure additional user profile attributes like user's Phone, Location, Department etc.

OAuth SSO Setup could be a complex procedure which requires correct configuration. It is essential to make sure every user’s access and permissions are set up properly. This is a time-consuming and tedious process and prone to errors which may lock you out!

How miniOrange SSO benefits administrators to setup SSO:

Use same SSO Setup as your Test Instance

If you are testing the setup at your test environment, you can use the same configuration to deploy to the production environment. With exported data, administrators do not need to reconfigure the entire setting again. This reduces entire setup time and chances of messing up configuration at the very critical system.

Export configuration from Test Instance using Backup plugin configuration file:

Administrators can export all plugin configurations in JSON format and import them at another instance via file transfer. The entire procedure can be done within minutes and is accessible to only administrators.

Use of the Rest API makes people's lives very very easy. As it is built to make remote calls to the server and easier to embed in the program, it is just an effortless way to communicate with the system you want.

The miniOrange SSO plugin lets you use the Rest API for your plugin configuration. Which brings you lots of scope to automate your manual and tedious work. You can couple this with your own system which will update your plugin configuration, with the data which you can get using the Rest API as well or download the file. Details of which you can find in the plugin.

As Rest API is a widely accepted protocol you won’t have much difficulty using it, and as far as your security is concerned miniOrange plugin provides Advanced Authorization for Rest API so rest assured that only verified admins have access to it.

How it will be used for Enterprise customers

Login into Atlassian Application through OAuth SSO creates an impact on user experience. We live in a civilization with a population of 7.8 Billion, each individual having a different perspective. Therefore it's very important that the products they use should fulfill their needs. A product that is static in its existence either in terms of language or User Interface creates a bad impression over the user experience. miniOrange OAuth SSO add-on breaks all such boundaries by providing customizable Login and Error Templates. This feature will help users around the globe to configure their own template depending on their use and needs.

How to modify and use the custom template

Working with miniOrange OAuth SSO Custom Template feature is quite easy. For the purpose of simplicity this feature is explained with the help of an image below.

Each Customizable Template section either be it Login or Error Template has an enable/disable button. Enabling that button gives users the ability to make changes in the Template Design Area. Now users depending upon their interest and need can code their own designed template and input it in this section and Save their changes by clicking on Save Button. Once changes are saved, they will be reflected when the user tries to login to the application again. By default miniOrange OAuth SSO add-on provides a Custom Login and Error Template but they can be modified by the user.

What if you go with Native SSO where Custom Template option is not available

SSO plugins provided by Atlassian Application are quite basic and static in its nature. The amount of user customization that can be done on those applications are almost negligible. In contrast to such add-on OAuth SSO add-on provided by miniOrange provides a vast range of user customizable features. At times when SSO fails and the user is not able to log into an application and an error is displayed with an unknown error, Custom Error Template can be quite useful at such times as users will have full flexibility to design their own error template.