Security Assertion Markup Language 2.0 (SAML) is the most commonly used Protocol for Single Sign-On (SSO). Absorb supports both this and OpenID as available SSO Protocols. In this article we will outline the different SAML workflows and how they interact with the LMS.

SAML Basic Workflows

SAML SSO can be divided into two main types: Identity Provider (IdP) Initiated  and Service Provider (SP) Initiated, depending on which system (the IdP or SP) activates the process.

The critical difference between these two types is where a User begins the process:

• With SP, the User starts by attempting to access the Service Provider: Absorb. The SP then sends the IdP a request containing some basic information about what the User is asking to do.
• With IdP, the User starts on their IdP and clicks a link in their Identity Provider to access Absorb. 

We recommend using Service Provider Initiated if possible, as several limitations may affect your SSO if you use Identity Provider Initiated.

Request vs Response

SAML SSO makes use of two specific call types: Requests or Responses. These can be defined as follows:

• Request: The SP sends a request to the IdP in the Service Provider Initiated flow to authenticate the User and redirect them after.
• Response: The IdP provides a response (also called a SAML Assertion) that contains User authorization and other provided details. The response will send the following information:
  • Signature: Includes the signature value that must be verified, as well as the certificate key and the encryption algorithm used. Absorb also supports directly uploading a Certificate during SSO configuration, which will automatically extract and populate the key field. 
  • Subject: Basic information on who the SAML response is about (e.g., their username).
  • Attributes: Additional information about the User. Note that in Absorb, attributes are only used for User provisioning.

Inbound vs Outbound

SAML SSO has two available settings when using the SP workflow: Inbound and Outbound. As implied by the names, this relates to the direction of the SSO. 

• Inbound SSO: The User accesses Absorb via authentication from an IdP. 
• Outbound SSO: The SSO connection initiates when the User is moving outside of Absorb, often via a tile set up on the Dashboard of the LMS, in tandem with settings in the SSO settings page. 

Unless there is a use case where clients want their Users to access materials outside of Absorb without authenticating (using Outbound SSO), most clients will use Inbound SSO. Inbound workflows send a request to a unique URL called an Assertion Consumer Service URL (ACS URL), which tells the IdP where to send its response once the user has logged in. It is a special URL that is ready for SAML responses and knows what to do with them. In Absorb, ACS URLs are route-specific.

Note that Inbound SSO is the only available setting for the IdP workflow. Please see the SAML Visual Workflow Comparison in the Attachments section to the right of this article for a visual comparison of the different workflows.

Identity Provider Initiated (IdP Inbound) Workflow

With IdP (Inbound), the User accesses Absorb through a link in their Identity Provider. This could resemble a tile on a "my apps" page or similar setup.

Identity Provider Initiated SSO can optionally require Users start at their IdP. To enable this, toggle on the Automatically Redirect option in your SSO Configuration. With this feature active, Users who navigate directly to the Portal URL are redirected to their IdP.

The process for IdP Inbound is:

1. User logs in using their IdP login page.
2. The IdP sends a request to the ACS URL.
   • Note that this URL is both client-specific (to the Absorb route) and interface-specific. 
3. Absorb then confirms that the IdP is who it claims to be by verifying the request signature using the provided certificate.
4. Absorb checks the NameID in the SAML response and matches it against Absorb using the Id Property. For example, if the NameID is Absorb.Test and the Id Property is Username, Absorb is checking for a Username of Absorb.Test.
5. If the User exists, matching the Id Property, the User is logged into Absorb and can begin their learning journey.

Service Provider Initiated (SP Inbound) Workflow

With SP (Inbound), the User starts by attempting to access Absorb LMS. Absorb then sends the IdP a request containing some basic information about what the User is asking to do.

The process for SP Inbound is:

1. The User navigates to a resource in their Absorb LMS instance (one that requires a login) and is redirected to their IdP along with a SAML request (see example below).
2. User logs in via their IdP login page if necessary.
3. The IdP sends a response to the ACS URL.
   • Note that this URL is both client-specific (to the Absorb route) and interface-specific. 
4. Absorb confirms that the IdP is genuine per the information on the signature provided.
5. Absorb checks the NameID in the SAML response and matches it against Absorb using the Id Property. For example, if the NameID is Absorb.Test and the Id Property is Username, Absorb is checking for a Username of Absorb.Test
6. If the User exists and matches the Id Property, the User is logged into Absorb and can begin their learning journey.
7. If the User doesn't exist, Absorb will display an error.

Direct Login on Absorb with an Active SSO - SP (Outbound)

Additionally, it is possible to set a unique password on Absorb while SSO is in use (e.g., for clients who aren't using SSO and their Learners log in directly via Absorb). However, this option has different considerations depending on if Service Provider Initiated or Identity Provider Initiated modes are used:

• Service Provider Initiated:  The route(s) associated with the SSO will automatically redirect to the SSO login page. In this case, a User would be able to log in using a route not associated with the SSO, or through the Admin route (for the SSO) if the User has admin access to the LMS (e.g., Company.myabsorb.com/admin).
• Identity Provider Initiated:  The User can log in using the login page for the LMS when the Automatic Redirect option is enabled in the SSO settings, provided that they have the correct URL.
  If Automatic Redirect is enabled in the SSO settings, this will cause the SSO to redirect the User to the SSO login page, similar to Service Provider Initiated process. In this case, they would need to use either a route not associated with the SSO, or log in through the Admin route if the User has admin access to the LMS (e.g., Company.myabsorb.com/admin).

The process for Direct Login is:

1. User logs into Absorb.
2. User accesses a resource that includes an SSO link to an external protected resource, e.g., a dashboard tile or, more commonly, a lesson in a course such as an AICC link (e.g. LinkedIn Learning).
3. The User is redirected to the service provider URL.
4. The SP sends a SAML request to Absorb.
5. Absorb confirms that the SP is who it claims to be by verifying the request signature using the provided certificate.
6. Absorb sends a SAML response to the SP (as above).
7. The SP verifies the response using Absorb's metadata.
8. If the User exists matching the Id Property, that User is logged into the SP.

Provisioning SAML

User provisioning (also known as Just in Time, or JIT provisioning) is when a User Account is created within a SP system when the User attempts to log in. 

This process follows the same incoming workflows discussed earlier in the article. The difference is when a matching User is not found, Absorb will try to create the User using attribute information in the SAML response rather than displaying an error.

Absorb currently only supports provisioning with SAML SSO. 

Glossary

Some of the below terminologies are specific to SAML, but similar concepts exist in all types of SSO (e.g., Open Id).