SSO - Getting started
  • 02 Nov 2020
  • 3 Minutes To Read
  • Print
  • Share
  • Dark
    Light

SSO - Getting started

  • Print
  • Share
  • Dark
    Light

Overview

Single Sign-On or SSO as the term suggests, allows for user authentication and access to multiple applications or websites with a single login event.

A user logging into an application or website with the SSO feature enabled would be able to log on to other applications listed by the Service provider, without the user having to key-in their login credential every single time for each of the applications.

How it works

Most websites or applications in this context, Document360 are termed as Service providers have a dedicated secure database for user information and their credential. But for applications or services that provide Single Sign-On feature an external entity, the Identity Provider or IdP is brought in, to ease the user experience in accessing the application.

Here’s a sequential rundown on how the Single Sign-on (SSO) feature operates

  1. The user visits the intended service provider or application domain sign-in page
  2. Redirection takes place to the Identity Provider (IdP) login page
  3. The user signs-in with correct credentials
  4. IdP domain matches the user information and sends an Access token or ID token to Service Provider
  5. The validation of the access/Id token with user information is successful on the Service provider’s end
  6. A trust relationship is established between the IdP and Service provider

As the authentication is successful the user is now authorized to access SSO enabled applications within the service provider without the whole process of Signing in for each instance

Identity Provider or IdP

An external entity that stores and manages the identity information of users; the IdP also authenticates the users by facilitating the Single Sign-On (SSO) feature. Identity Provider handles the credentials that users use to log in to web applications, file servers, systems, and other digital services. Any single entity stored by the IdP is referred to as a ‘principal’.
Single Sign-On feature is established with two broad standard protocols adopted by Service providers.

  1. SAML
  2. OpenId

SAML

A Security Assertion Markup Language (also SAML 2.0) is an open standard protocol that enables Single Sign-On that provides authorization and authentication to web-based applications in this case Document360.

There are three prime entities to consider in this process: The Identity Provider (IdP), the Service provider, which is Document360, and the User Agent which is the user’s web browser.

With SAML 2.0, a trust relationship (XML metadata exchange) is established between the Service provider and the Identity Provider (IdP).

  1. When users want to access the Service provider, they must first authenticate into the IdP
  2. Post authentication the user would be authorized by the IdP
  3. The IdP generates a SAML Assertion (with user identifier information and digitally signed)
  4. The SAML Assertion is sent to the Service provider via the User agent
  5. The Service provider then validates the Assertion
  6. As the Service provider holds a trust relationship with IdP, the user is allowed access

As the authentication is already completed by the IdP, the user has the privilege of Single Sign-On and can access other Service providers configured with the IdP.

OpenID

OpenID connect (OIDC) is an open standard that is built on the OAuth 2.0 protocol, which gives OpenID an additional layer of security. There are three entities in this standard of the Single Sign-On process: The End user, the Service provider and a third-party Identity Provider (IdP).

With OIDC here is the flow of process when a user wants to access a Service provider.

  1. The user selects the OAuth on the service provider page
  2. The user is redirected to the Identity Provider (IdP)
  3. Using the credentials entered the user is authenticated
  4. The IdP then sends an Access Token (credentials to provide access to API) back to the Service provider; an ID token (a JSON Web Token or JWT with the ID data) is also relayed on request
  5. The Service provider then retrieves the user info from the ID token or use the Access token to verify
  6. An SSO session is established between the IdP and Service provider

The user gains authorization to access the SSO enabled service provider (Document360) without having to authenticate with credentials for each instance.

Was This Article Helpful?