Single Sign-On (SSO) is an authentication method that allows Users to log into multiple applications with one set of credentials. This service authenticates a User on one platform, enabling them to easily log in to several internal services without having to log in and out each time.

At a basic level, SSO is an agreement between three entities:

• Users: A User is an individual who requires access to different services.
• Identity Providers (IdP): An IdP stores the User's information in a database. It may also include additional attributes about the User's identity, like an email address, and pass that information to a Service Provider.
  • Examples of IdPs include: Microsoft Azure, Auth0, Okta, OneLogin, and Absorb LMS.
• Service Providers (SP): The term Service Provider (SP), is a formal way of identifying an application or service that Users need to sign-in to access. The definition of an SP extends beyond websites and web applications.  For example, to use some organizations' Wi-Fi networks, you must use the same username/password combination as your company email. In this scenario, the organization's Wi-Fi is an SP (and you authenticate by using SSO).
  • Examples of SPs include: Absorb LMS, Dayforce, Jira, and Confluence. 

Benefits of Using SSO

There are a variety of use cases for SSO. Some common reasons for using SSO include:

• Simplification: With SSO, Users only need to remember a single username/password combination for their Identity Provider (IdP). Once authenticated with the IdP, the User is automatically logged in to all of their organization's Service Providers (SP).
   
• Access Provisioning: SPs that offer to provision can help automate new hire accounts for the organization's other services.
  
  Example: Virginia has been hired by Robotech. Robotech uses the following SPs: Absorb LMS, Dayforce, and Office635 email accounts.
  • If Robotech doesn't use SSO, new hire accounts will need to be manually created by a member of Robortech's staff (usually HR or IT).
  • If Robotech uses SSO, Virginia will only need to have an account with Robotech's IdP.  When Virginia first attempts to access Absorb LMS through SSO, provisioning will automatically create within Absorb LMS using the fields provided by the configuration of the SSO provisioning.
     
• Access Deprovisioning: Similarly, if an employee leaves a company, the company only needs to disable their account in the IdP, and the employee will automatically no longer have access to any of the service providers behind it.
  
  Example: Jane is retiring from Robotech. Once she's retired, the company can disable Jane's account in their IdP. Since all of Robotech's service providers rely on Jane signing into the IdP first, and because Jane can no longer sign in to the identity provider, Jane won't be able to access any of the service providers.

How does SSO work?

SSO transfers the User’s identity from the IdP to the SP. There are a few different ways for the User's identity to be transferred, using communication methods known as Protocols.

The most commonly used and supported SSO protocol is the Security Assertion Markup Language 2.0 (SAML). When a User logs into a SAML-enabled application, the SP requests authorization from the appropriate IdP. The IdP authenticates the User's credentials and then passes the authorization for the User to the SP. The User is now able to use the application.

SSO Authentication Process

1. User attempts to access a service provider (e.g., Absorb LMS), either by clicking on a link, visiting a bookmark, or some other way.
2. The SP sends a Request over to the IdP: "Who is this person?"
3. The User logs into the IdP, which tells the IdP who they are.
4. The IdP sends a Response to the SP: "This is jane.donut, sign them in please."
5. The SP signs the user into the jane.donut account.

The above steps must be completed in a secure way. Absorb ensures this in both requests and responses by using Certificates. It is essential that Absorb's SP is communicating with the correct IdP and not another (potentially malicious) entity posing as your organization.

Likewise, the IdP also wants to be sure it's sending information to the correct SP. These Certificates are like a secret handshake used to verify that the LMS is communicating with the correct person, and to help ensure the safety of your data.

External Learners and SSO

Organizations may need to provide training to Learners outside of their organization. Learners who are not employees will not be able to access the training through the typical SSO link in Absorb LMS emails. External Learners must access training through a separate Portal. For more information, see the External Learners & Single Sign-On (SSO) article. 

SSO Protocols

There are two major SSO protocols supported by Absorb: SAML and OpenID Connect. Confirm with your organization which protocol you will be using. 

1. SAML: Initially published in 2001, SAML is an XML-based Markup Language and can be configured as either Identity Provider Initiated, or Service Provider Initiated (recommended). More information can be found in the SAML SSO article. 
2. OpenID Connect: Published in 2014 OpenID Connect is the 3^rd iteration of the OpenID protocol after OpenID and OpenID 2.0. OpenID Connect uses JSON Web Token (JWT) signature types. More information can be found in the SSO Considerations and OpenID Connect Single Sign-On articles. 

Single Logout (SLO) Process

Single Logout (SLO) is a complementary process to SSO that ensures a User is logged out from all applications that they accessed through SSO using the same credentials. SLO reduces the manual workload for Users by logging them out from all sessions, where they would instead have to log out from each session manually without SLO. 

SLO is available for Incoming SAML configurations using either Identity Provider Initiated or Service Provider Initiated modes. More information about SLO can be found in the Configuring Single Logout (SLO) article.