Single Sign-On Implementation Analysis

3 July 2014 | Articles

By Douglas Fidelis

This article will show the concept of SSO and the application of this technology recently implemented by e-Core for one of our clients.

First of all, what is SSO? 

Single sign-on (SSO) is a property of access control of multiple related yet independent software systems. With this property, a user logs in once and gains access to all systems without being prompted to log in again on each of them.

Why should a company use it?

Well, this will make the user experience better, save time and guarantee that the swap between applications runs seamlessly and securely, once the user won’t need to provide access information every time the systems redirect him/her to different applications.

Our client has its own platform including several applications, and it must be integrated for all client websites, to offer the possibility for the final user get all information needed from multiple places without the need to log in multiple times.
Lets see this scenario.

Member portals -> Clients -> Final users (customers)

Our client provides private information, such as billing details, only for users that have access to the member portals,

End users will only have access to Clients portal, so they have a user/password that applies only for Clients portal, but they wont’ have access to all member portals.

How can customers check billing information if they don’t have permission to that? Creating user credentials for each customer would mean a massive amount of data and processing increase, so it wouldn’t be the best choice.

Using SSO, our client can provide a way for its end users to member portals through their own portal. They only provide a link, that will have key information to sso process, and it will do the authentication process.

So this is a process between our client <-> end users

  1. A user has logged on to the IdP (Identity Provider).
  2. The user requests access to a protected SP (Service Provider) resource. The user is not logged on to the SP site.
  3. Optionally, the IdP retrieves attributes from the user data store.
  4. The IdP’s SSO service returns an HTML form to the browser with a SAML* response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.
  5. If the signature and assertion are valid, the SP establishes a session for the user and redirects the browser to the target resource (red box).*SAML = Security Assertion Markup Language (SAML, pronounced “sam-el”) is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.

Read more:

3 Marketplace Apps for your Confluence!

 The Atlassian Marketplace is a portal that provides access to many apps that will optmize tools that you use, like Jira, Confluence, Bamboo and others. In addition, you can differentiate yourself by your integration potential. It allows customers to discover and...

6 Common Questions When Licensing

We know that at the time of purchase and / or renewal of licenses of Jira, Confluence or other Atlassian tool, some doubts arise. In an effort to help you solve some of them, we've chosen the key issues we're addressing at the moment. Are additional licenses required...

Share This