In the context of EasySSO the use case for SAML can be summarised in two words - “external users”. 

“Our government agency allows other agencies access to our JIRA Software and Confluence for the purposes of collaboration. Federated identity solution is in place and authentication is performed against the user’s agency identity management system and successful results are conveyed to our system using SAML 2.0 protocol. This applies to our own users when they access the system from outside our networks.

At the same time for our internal users accessing our systems from within the office or via VPN we prefer Kerberos at it avoids login screens altogether and removes barriers to collaboration completely.

EasySSO provided us with the best-of-both-worlds solution"

"External users" includes internal users who access the application from Internet as well as users from other organisations that require access. While the internal users often have a choice of using VPN and thus enjoying the same level of convenience as when being in the office when it comes to SSO – through the use of Kerberos or NTLM (depending on how the VPN is configured and if their workstation has direct access to Domain Controllers), the true externals are most likely non-domain users i.e. neither Kerberos nor NTLM would work for them.

Configuring SAML in this case allows to authenticate such users. Often this includes enforcing some form of 2-factor authentication at the level of SAML Identity Provider.

To configure EasySSO to talk to the SAML provider of your choice please see EasySSO with SAML - Configuration.

The Flow of Information

The flow of the information is as follows:

  1. The client browser accesses Atlassian application.

  2. EasySSO identifies that the user is not authenticated yet.

  3. EasySSO identifies SAML SSO is to be performed.

  4. The client browser is redirected to the Identity Provider.

  5. The Identity Provider performs authentication e.g. request the user to login via web form — this is where the verification may involve communication with different independent organisations e.g. agencies or universities

  6. The Identity Provider then redirects back to the EasySSO-enabled Atlassian application, including SAML 2.0 “ticket”.

  7. EasySSO extracts the information from SAML 2.0 “ticket”.

    1. If the user doesn’t exist, a user record is created based on the username, full name, and email provided in the SAML 2.0 “ticket”.

    2. The new user is added to the specified group/s automatically.

  8. The user is logged in.

EasySSO articles

Try for free

EasySSO for Jira, Confluence, Bamboo, Bitbucket and Fisheye/Crucible

Try for free