Data Center SAML SSO:

Missing Usecases in Native Atlassian 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 Server to Data Center for Atlassian applications, users now have the option to login using the in-built SSO functionality provided by Atlassian in Data Center. The in-built SSO functionality supports SAML into the Data Center Atlassian instance using an external Identity Provider (IdP). Users will be able to access all Atlassian Data Center applications with the credentials of the Identity Provider.

miniOrange with it’s SAML SSO apps 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 10 crucial use cases which are covered by the miniOrange Single Sign On apps.

Use case 1: Fine Grained Access Based Control

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 SAML Single Sign-On (SSO) 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.

Some of these rules can be -

  1. Mapping set of groups or permissions to internal and external users.
  2. Assigning internal and external users to specific directories.
  3. Having fixed domains for internal and external users.
  4. Or even having different application URL for internal and external user login.

In short, you just have to define differentiator factors for users and the rest will be handled by the miniOrange SAML SSO plugin.

One more differentiator factor can be IPs or IP Range. We need to set an IP range in the miniOrange SAML SSO plugin for internal and external users and you are good to go.

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.

Use case 2: SSO for Jira Service Management

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 Identity Provider which is common for Jira Software and Service Management. The same SAML SSO settings will work out of the box for Jira and Service Management.

You can enable and disable Jira Service Management SAML 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 Identity Providers (IDPs)

Here you can configure dedicated IDPs for Jira Software and Jira Service Management and user roles and permissions will be managed by that particular Identity 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 3: Destroy all applications session using single click

This can be achieved with Single Logout (SLO) functionality and is supported by SAML SSO protocol.

Now, what is Single Logout? Let’s consider the ideal case where Jira and Confluence Data Center are connected with the Identity Provider (IDP). So

  1. when you log out from Jira you get logged out from Identity Provider and the other applications connected to the IDP such as Confluence.
  2. when you log out from Identity 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 IDP 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 IDP 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 4: 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 SAML SSO and Provisioning the user groups

In a situation without SAML 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 Identity Provider (IDP) 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 Identity Provider (IDP) 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 Identity Provider (IDP) based on your requirements.

A few cases which are supported -

  1. Some groups are present in IDP and the rest are locally created to manage users.
  2. All local groups are different than IDP.
  3. All or some groups in IDP are present in the local Atlassian applications but with a different name.
  4. All groups in IDP are present in local Atlassian applications with the same name.

With Atlassian Data Center’s in-built SSO or native SSO, you can sync IDP groups to local groups with the same names but all other cases will not be fulfilled. You will not be able to manage Identity 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 a 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 5: Do not show Jira 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 Identity Provider user login page. Local users can log in via the Jira Data Center Login page and others can ask to authenticate through SSO, who will get to see the IDP 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 SAML SSO too. Then you might be wondering what difference it will make to use miniOrange's SAML SSO ?

Let’s say, unfortunately your IDP 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 SAML 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 the 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.

Use case 6: Secure SAML using Signed and Encrypted Assertion

Why encrypt and Sign SAML Assertions?

In today's world, everybody understands the importance of data security. Due to the huge rise in the number of cyberattacks, data security has become a top priority for each and every business. In SAML SSO, Encrypting and signing the SAML assertions is the way to ensure that your sensitive information is never visible in plain sight.

A number of organizations and standard bodies either recommend or require sensitive data to be encrypted in order to prevent unauthorized third parties or threat actors from accessing the data. Encryption is the method by which information is converted into secret code that hides the information's true meaning. Signing verifies the sender of the data. Encryption plays an important role in securing many different types of assets. Encryption provides Confidentiality, Nonrepudiation, Data Integrity, and Authentication.

Atlassian Data Center does provide the option to enforce SSO on users. So do miniOrange's SAML SSO too. Then you might be wondering what difference it will make to use miniOrange's SAML SSO ?

What does miniOrange SAML SSO provide?

Many Identity Providers offer data security features, but Atlassian’s Native Data Center SSO lacks this level of security type of data, making your security efforts pointless and your application vulnerable to a wide range of attacks. Some severe attacks include Identity theft, where the attacker impersonates an end user's identity. If your administrator account gets compromised then you can say goodbye to all your confidential data.

You can protect your data with encryption and signature checks using miniOrange. The sensitive data sent by the Identity Provider will be encrypted and signed with a key. This data will be accepted only if it passes all the security checks. miniOrange also provides you with the ability to configure your own secret keys for encryption and signature verification. The miniOrange plugin makes your SAML SSO more secure than it has ever been.

What Our Customers Say

Our SAML SSO Data Center Apps

Hello there!

Need Help? We are right here!

Contact miniOrange Support

Thanks for your inquiry.

If you dont hear from us within 24 hours, please feel free to send a follow up email to