Single sign-on (SSO) is the ability for users to login into corporate apps, websites, and data for which they have permission using a single set of credentials. 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 the Data Center. The in-built Atlassian Data Center SSO functionality supports SAML SSO into the Data Center Atlassian instance using an external Identity Provider (IdP). Atlassian Single Sign-On/Atlassian SSO for Data Center allows users to access all Atlassian Data Center applications with the credentials of the Identity Provider.
miniOrange with its SAML SSO applications also supports login into Atlassian applications such as Atlassian Jira Data Center SSO and Atlassian Confluence Data Center SSO, 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 Single Sign-On(SSO) apps and the in-built SSO functionality provided by Atlassian?
Use case 1: Fine Grained Access Based Login Control
Enterprise organization infrastructure is complex and there is always a problem of how to manage internal and external user logins in 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 ensure a smooth user login experience? Well, it is not that difficult when it comes to the miniOrange SAML Single Sign-On (SSO) plugin.
You simply have to define certain rules on the user set or you could be already using those rules for managing internal users and external users.
Here is an example of some of these rules -
- Mapping set of groups or permissions to internal and external users.
- Assigning internal and external users to specific directories.
- Having fixed domains for internal and external users.
- Or even having different application URL for internal and external user login.
In short, you have to define differentiating factors for users and the rest will be handled by miniOrange SAML SSO plugin.
One more differentiating factor can be IPs or IP Range. We need to set an IP range in the miniOrange SAML SSO plugin for internal and/or external users and you are good to go.
For any users not falling into any of the differentiator factors a default setting can be set.
Let’s consider an example of Domain based mapping for Internal users and External users.
Use case 2: SAML SSO for Jira Service Management (JSM/JSD)
Jira Software and is widely used by many organizations as a ticketing tool and Jira Service Management helps organise and prioritise service requests, problems and incidents. Since it is an end user interaction tool the user base is huge. Along with a big user set the responsibility of handling and managing is sizable.
Here comes miniOrange solution with great user experience for Jira Service Management. The best thing about miniOrange solution is that 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 also choose to configure a separate Identity Provider for your Service Management users.
You can enable and disable Jira Service Management SAML Single Sign On (SSO) using a simple toggle button.
If you are wondering how the user experience will be if you use multiple identity sources or have dedicated identity sources for Jira Software and Service Management login, you don’t need to worry, 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 a seamless and smooth login experience to you and will make it easy to manage and maintain users.
SSO for only Service Management Agents
You can choose to restrict SSO for agents only. This ensures that only Jira Service Management agents are allowed to login into the Data Center through SSO 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.
Local 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 and Confluence credentials.
Use case 3: Terminate session from all the connected applications using a 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 Atlassian Jira Data Center and Confluence Data Center are connected with the Identity Provider (IDP). So
- when you log out from Jira you get logged out from Identity Provider and the other applications connected to the IDP such as Atlassian Confluence, Bitbucket, Bamboo, Fisheye & Crowd.
- when you log out from Identity Provider you get logged out from Atlassian applications such as Jira ,Confluence, Bitbucket, Bamboo, Fisheye & Crowd.
Ease of Single Logout(SLO)
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.
In Single Logout, a user gets logged out automatically from all Atlassian applications which are connected to the IDP if a logout operation is performed for any of the applications.
What if you go with Native Atlassian Data Center SSO where Single Logout is not available?
If we don’t have an option of Single Logout, we would need to always depend on the user to logout of each application individually. Generally, the sessions for these Atlassian applications (Jira, Confluence) are very long and they are active for a long time. If you don’t logout from the IdP explicitly a third party can log into the IdP session to get hold of Atlassian Jira or Confluence account.
Use case 4: Manage user permissions in Jira/Confluence 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.
Administrators can associate particular access rights to the groups, which in turn get applied to the users who belong to that group.
Atlassian Data Center 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.
Here is a brief of a few cases that are supported -
- Some groups are present in IDP and the rest are locally created to manage users.
- All local groups are different than IDP.
- All or some groups in IDP are present in the local Atlassian applications (Jira, Confluence, Bitbucket, Bamboo) but with a different name.
- 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).
When Atlassian Jira/Confluence Data Center SSO is synced with an external directory, and permissions for directory is Read Only with Local Groups, you can simply assign local Jira/Confluence groups to the user and manage your user permissions within Atlassian Jira/Confluence itself while turning on SSO for all your users.
Use case 5: Do not show Jira/Confluence Login page for Authentication
Once the Single Sign On integration for Atlassian Jira or Confluence 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 the Data Center local user and Identity Provider user login page. Local users can login via Atlassian Jira and Confluence Login page and others can ask to authenticate through SSO and 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 does miniOrange's SAML SSO too. Then you might be wondering what difference will it make to use miniOrange's SAML SSO ?
Let’s say unfortunately your IDP goes down or you have messed something up which causes an error while performing Atlassian Data Center SSO. Then what? Your users will be locked out and won't be able to access their own account and data. Things will not stop here, even you being the admin won't be able to access the default login page to get into the Atlassian Jira SSO/Atlassian ConfluenceSSO. You wouldn’t have any option but to raise a support ticket to the Atlassian and keep waiting. You will then need a way to bypass the Single Sign-On(SSO) for the time being.
Emergency URL for Atlassian 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 Atlassian Data Center 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. It is configurable so the admin gets to decide what it should be. Thinking about more Data Center 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, Encrypted and Restrict Duplicate Assertion
Concerned about user data security/safety? Enable Signed Requests!
In recent times it’s become easier to slip sensitive information over to unintended parties. In light of these circumstances, you would not want to be left vulnerable and turn in confidential user data. Normally during SAML SSO, requests are sent over to the IdP in an encoded format, which the IdP decodes.
These requests can be captured by a man in the middle or a third party to decode! These pirate requests can then be sent to the IdP while the session is still valid, allowing these bodies to exploit or receive the confidential data in the SAML response.
Enabling Signed Requests appends a digital signature over to this SAML request, which adds a layer of security. This feature ensures that the Identity Provider is certain of unaltered SSO requests, owing to this digital signature.
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, you can encrypt SAML assertions to ensure your sensitive information is hidden.
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 Data Center Single Sign-On (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 Data Center SAML SSO more secure than it has ever been for Atlassian Jira SSO, Atlassian Confluence SSO.
Prevention against SAML replay attack (Restrict Duplicate SAML Assertion)
Replay attack is the common man-in-the-middle security threat which includes repeatedly sending SAML assertions to the system. This will allow the attacker to login into a secure application with user privileges of the username/ email mentioned in the SAML response.
miniOrange prevents such attacks by tagging each session with a time bound ID. This ID is further checked for duplication when a user tries to SSO. So, in case an attacker reads a SAML Response assertion of a valid user and tries to use it again, the miniOrange SSO apps reject the SAML Response despite it being valid due to the ID already being used once.
Secure login for admin users
In Atlassian, administrators have to login and reauthenticate to get privileged access. In keeping with this and to add more protection to admin functionality, you can configure the miniOrange Jira Data Center SSO and Confluence Data Center SSO apps to force all users to login as a user without the admin privileges. Admin users will have to authenticate again to get the admin privileges, resulting in increased security.
Use case 7: Conveniently Modify Username and get logged in
Regular Expression, regex for short, is a strong tool for performing string search and manipulation operations. There might be some cases where you want your attribute value in a particular format but your IDP’s SAML response attribute values are not the same as the format you want or you prefer. In such scenarios regex comes in very handy.
Consider a situation where the user's username needs to be extracted from his or her email ID “email@example.com”. First enter the attribute name containing the user's email in the Username field. After applying the regex.*?(?=@) in the regex field, the entered expression will extract the value “user” and display the username in the user's profile.
Use case 8: One-click configuration setup
SSO Setup is 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 for Atlassian apps:
Use same SAML 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.
IDP updated their certificate? Not to worry! Would it not be tiresome to have to delegate with the IDP provider for each iteration when it’s time to update the metadata content. Having to follow procedures for replacing certificates to allow SSO without any service disruptions. Some IDPs update their certificates regularly as a security measure so only trusted service providers are in possession of the updated certificate.
The miniOrange SAML SSO plugin comes in very handy with the certificate rollover feature which makes it possible to perform a certificate rollover to ensure no interruption during Single Sign On. In order for Service Providers to be aware of an IdP certificate, SAML metadata includes the certificate of the IdP. Simply enable the metadata rollover and set up the frequency of update less than or equal to that of the IDP update frequency. This will ensure seamless uninterrupted Atlassian Jira SSO functionality all while you lounge without you having to manually configure a thing.
Use case 9: Configurations using REST APIs
Use of the Rest API makes people's lives very very easy. Since 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 for Atlassian Jira SSO, Atlassian Confluence SSO 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 by using the JSON format. This can be downloaded or fetched from REST API. 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. As far as your security is concerned miniOrange plugin provides Advanced Authorization for Rest API so be rest assured that only verified admins have access to it.
Use case 10: Design your own Login, Logout and Error page
How it will be used for Enterprise customers
Login into Atlassian Application through 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 impact on user experience. miniOrange SAML SSO add-on breaks all such boundaries by providing customizable Login and Error Templates. This feature will help users to configure their own template depending on their use and their needs.
How to modify and use the custom template
Working with miniOrange SAML SSO Custom Template feature is quite easy. For the purpose of simplicity this feature is explained with the help of an image present below.
Each Customizable Template section like Login or Error Template has an enable/disable button. Enabling that button gives users the ability to make changes in the Template Design Area. Administrators 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 the Save Button. Once changes are saved, they will be reflected when the user tries to login to the application again. By default miniOrange SAML SSO add-on provides a Custom Login and Error Template but they can be modified by the user.
What if you go withAtlassian Native SSO where Custom Template option is not available
SSO plugins provided by Atlassian Application are quite basic and static in nature. The amount of user customization that can be done on those applications are almost negligible. In contrast to such add-ons, Jira Data Center SSO and Confluence Data Center SSO add-on provided by miniOrange provides a vast range of user customizable features. At times when Single Sign-On (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.
Table of Contents
- Fine Grained Access Based Login Control
- SSO for Jira Service Management
- Single click Terminate All Sessions
- Manage user permissions in Jira Data Center
- Do not show Jira Login page for Authentication
- Secure SAML using signed & encrypted Assertions
- Conveniently Modify Username and get logged in
- One-click configuration setup
- Configurations using REST APIs
- Design your own Login, Logout and Error page