Want to learn more about SSO? Check out our SSO Curriculum on Absorb Academy! Please be advised you must be signed into Absorb Academy in order to access this course.
An Introduction to SSO
What is SSO?
SSO stands for Single Sign-On. It's an authentication method that allows users to log into multiple applications with one set of credentials. Its beauty is in its simplicity; the service authenticates you on one platform, enabling you to transparently login to several internal services without having to log in and out each time. SSO at a basic level is an agreement between three entities:
- Users
- A User is an individual who needs to access 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 (SP).
- IdPs: Microsoft Azure, Auth0, Okta, OneLogin, and Absorb LMS.
- Service Providers (SP)
- The term "Service Provider" or SP is a formal way of identifying an application or service that Users need to authenticate (sign-in) to access.
- The definition of an SP isn't limited to websites or 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!)
- SPs: Absorb LMS, Dayforce, Jira, and Confluence.
Example: Not Using SSO | Example: Using SSO |
---|---|
When not using SSO, the User must remember the username/password combination for each Service Provider (SP). | When using SSO, the User only needs to remember a single username/password combination: that of their Identity Provider (IdP).
Once authenticated into their IdP, the User is "signed-in" to all of their SPs. |
Benefits of Using SSO
There are a variety of use cases for SSO. Among them, some of the common ones are:
- 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: Service Providers (SP) that offer to provision (e.g. Absorb!) can help automate new hire accounts for all of the organization's other services.
Example: Virginia has been hired by Robotech. Robotech uses the following Service Providers (SP): 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 Identity Provider (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, to the above point, if an employee leaves a company, the company only needs to disable their account in one location, the Identity Provider (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 understandably doesn't want her accessing any of its internal services. All the company has to do is disable Jane's account in their identity provider. Since all of Robotech's service providers rely on Jane signing into the identity provider 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 works by transferring the user’s identity from one place (the Identity Provider (IdP)) to another (the Service Provider (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 & supported SSO protocol is the Security Assertion Markup Language 2.0 (SAML for short). When a user logs into a SAML-enabled application, the service provider requests authorization from the appropriate identity provider. The identity provider authenticates the user's credentials and then passes the authorization for the user to the service provider and the user is now able to use the application.
SSO Simplified
- User attempts to access a service provider (e.g., Absorb LMS), either by clicking on a link, visiting a bookmark, or some other way.
- The service provider sends a request over to the identity provider: "Who is this person?"
- The user logs into the identity provider, which tells the identity provider who they are.
- The identity provider sends a response to the service provider: "This is jane.donut, sign them in please."
- The service provider signs the user into the jane.donut account.
The above must be done in a secure way. As such, our requests and responses are with certificates. Our service provider wants to make sure that the identity provider it's talking to is the identity provider it should be talking to and not some other (potentially malicious) entity posing as your organization.
Likewise, the identity provider also wants to be sure it's sending information to the correct service provider. Without going into too much detail, these certificates are like a secret handshake used to verify that who the LMS is communicating is correct and help ensure the safety of your data.
SSO Protocols
There are two major SSO protocols supported by Absorb. SAML (short for Security Assertion Markup Language) and OpenID Connect. Absorb supports both methods and a time of writing, SAML is currently the most common setup used for SSO. Unless your organization is just starting to investigate SSO and is working to decide what’s best, it is likely that the Protocol you will be using has already been determined.
- 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 (Covered in the next section).
- OpenID Connect: Published in 2014 OpenID Connect is the 3rd iteration of the OpenID protocol after OpenID and OpenID 2.0. OpenID Connect makes use of RESTful API & JSON
SAML SSO
SAML Basic Workflows
There are two main types of SAML SSO: Identity Provider Initiated (IdP) and Service Provider Initiated (SP), depending on which system (the IdP or SP) activates the process. We recommend using Service Provider Initiated if possible as several limitations may affect your SSO if you use Identity Provider Initiated. The critical difference between IdP and SP is where the whole process starts:
- With SP Initiated, the user starts by attempting to access the Service Provider: Absorb. Then Absorb (the SP) 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.
Note: When users have a direct URL to your organization's Absorb LMS portal (e.g., Company.myabsorb.com), an IdP SSO will redirect to the SSO login page if the Automatic Redirect function is enabled.
Request VS Response
SAML SSO makes extensive use of two specific call types: Requests or Responses. These can be defined as follows:
- Request: A request is sent by the SP to the IdP in the Service Provider Initiated flow to request to authenticate the user and redirect them afterward.
- Response: A response (also called a SAML Assertation) contains user authorization and other details provided by the IdP; and will send Signature, Subject, and Attributes.
Inbound VS Outbound
SAML SSO has two possible settings when using Service Provider Initiated (SP): Inbound and Outbound. As implied by the names, this relates to the direction of the SSO.
- Inbound SSO: An Inbound SSO refers to the user coming into Absorb via authentication from an IdP.
- Outbound SSO: With 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.
IdP (Inbound)
With IdP (Inbound), the user starts on their identity provider and clicks a link in their identity provider to access Absorb (via a "my apps" page or something similar).
(Optional) Identity Provider Initiated SSO requires the user to start at their IdP. To facilitate this, the Automatically Redirect option must be enabled within the Absorb LMS > Portal Settings. With this feature active, users are automatically redirected to their IdP when they attempt to access Absorb.
- User logs in via their IdP login page.
-
The IdP sends a request to a unique Absorb URL (called the ACS URL; more on this later)
- This URL is both client-specific (to the Absorb route) and interface-specific.
- Absorb then confirms that the IdP is who it claims to be by un-encrypting the request signature/certificate using the provided certificate key.
-
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
- If the user exists, matching the Id Property, the user is logged into Absorb and can begin their learning journey.
SP (Inbound)
With SP (Inbound), the user starts by attempting to access Absorb LMS; Absorb sends the IdP a request containing some basic information about what the user is asking to do.
- 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)
- User logs in via their identity provider login page if necessary.
-
The identity provider sends a response to a unique Absorb URL (called the ACS URL; more on this later)
- This URL is both client-specific (to the Absorb route) and interface-specific.
- Absorb confirms that the identity provider is genuine per the information on the signature provided by the IdP
-
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
- If the user exists, matching the Id Property, the user is logged into Absorb and can begin their learning journey.
- If the user doesn't exist, Absorb will display an error.
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 functionality will be different if using Service Provider Initiated or Identity Provider Initiated.
- Service Provider Initiated: The route(s) associated with the SSO will automatically redirect to the SSO login page if enabled. 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: When the SSO settings have the Automatic Redirect option enabled, the user can log in on the login page for the LMS, provided 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 when using Service Provider Initiated. 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
Service Provider Initiated Outbound Workflow
- User logs into Absorb.
- 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)
- The user is redirected to the service provider URL.
- The service provider sends a SAML request to Absorb.
- Absorb confirms that the identity provider is who it claims to be by un-encrypting the request signature/certificate using the provided certificate key.
- Absorb sends a SAML response to the service provider (as above)
- The service provider verifies the response using Absorb's metadata.
- If the user exists matching the Id Property, that user is logged into the service provider.
Provisioning SAML
User provisioning (also known as Just in Time, or JIT provisioning) is when a user account is created within a service provider system when the user attempts to log in.
This process follows the same incoming workflows as above. Still, 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.
Requests and Responses (SAML)
Request
A request is sent by the Service Provider (SP) to the Identity Provider (IdP) in the Service Provider Initiated flow to request that a user be authenticated. It asks the Idp to authenticate the user, and where to send the user afterward.
An Assertion Consumer Service URL (ACS URL) tells the Idp where to send its response once the user has logged in. It's a special URL that is ready for SAML responses and knows what to do with them. In Absorb, ACS URLs are route-specific.
Click here to download a SAML Visual Workflow Comparison.
Response
A response contains information from the identity provider with the user's authorization (this is also called a "SAML Assertion"). It's made up of a few key parts:
- Signature: Includes the signature value that must be unencrypted, as well as the certificate key and the encryption algorithm used.
- Subject: Basic information on who the SAML response is about (e.g., their username).
- Attributes: Additional information about the user. In Absorb, attributes are only used for user provisioning.
Terminology
Some of the below terminologies is SAML specific, but similar concepts exist in all types of SSO (e.g., Open Id)
Term | Definition |
---|---|
Key/Certificate | The key is used to confirm that both parties are who they say they are, which helps protect the security of the user and their data. The certificate in Absorb is expected to be in X.509 (base 64) format. |
Request | The part of the SSO workflow where the service provider asks the identity provider to start the authentication process. |
Response | The part of the SSO workflow where the identity provider sends the service provider information on whether the user is allowed to log in. |
Assertion Consumer Service (ACS) URL | An endpoint on the service provider where the identity provider will redirect to with its authentication response. |
POST | A method of sending data over HTTP to another server. |
Signature Type | The type of encryption used for communication (typically SHA256 - Secure Hash Algorithm) |
Id Property | The property used to identify the user. For example, if the Id Property is username, Absorb is expecting to receive a username in responses. |
Incoming Single Sign-On | User is being signed into Absorb from another site (note that this will often be reversed if the other party is talking!) |
Outgoing Single Sign-On | User is being signed into another site from Absorb (note that this will often be reversed if the other party is talking!) |
SAML Trace(r) | An application or browser add-on that allows you to view a SAML request or response. |
Identify Provider (IdP) | This is the website, service, etc. that authenticates the user. |
Service Provider (SP) | This is the website, service, etc. providing the resource that the user wishes to access. |
Security Assertion Markup Language (SAML) | Most commonly used standard for SSO. |
SSO Considerations
1. What Type of SSO does your organization want? |
Absorb is the identity provider in this case. |
2. Which protocol is your organization going to use? |
Absorb only supports Open Id Connect.
|
3. Which ID Property (NameID) is your organization going to use? |
Your organization will need to decide how the identity provider will identify the user to the service provider. Whichever method you use needs to be present on BOTH platforms. At the time of writing, Absorb supports the following Id Property options on SAML; however, Open Id Connect can only use Email Address:
Note: The ID Property must be populated for all users who will be using the SSO. This value is used to match the field in the LMS to the attribute provided by the SSO. Often clients will choose to use the External ID field from Absorb, as an LMS admin cannot edit this field through the Admin interface. Absorb ID refers to the GUID (Global Unique Identification) set generated by the system when a user's account is created. Because of this, this is not recommendable for use with User Provisioning. |
What are the Identity Provider and Service Providers' Certificates? |
You will need two certificates. The identity provider and service provider each have their own certificate and you will need to exchange them with each other.
|
Do you want User Provisioning? |
Do you want Absorb to create users if they don't exist? If so, bear in mind that you will need to set up their identity provider to send the required attributes to Absorb. Learn more: More details are in Incoming SAML 2.0 SSO Account Provisioning article. |
Which Portal Routes do you want to be associated with the SSO? |
If your portal only has one route this is simple, but if your portal has multiple then you can decide which URLs you want to have associated with this SSO configuration. Other routes can be attributed to other SSO configurations (if you have any), or you can keep them unassociated. Note: Routes that aren't associated with an SSO configuration will work as though the portal does not have SSO set up for those specific routes (i.e., users will see the regular Absorb login screen/dashboard). |
Configure your Identity Provider |
You or your IT will need to configure your identity provider. Absorb does not directly assist with this, but we do have a few articles on how to do so with popular identity providers (A list of these articles is available at the end of this article), You’ll need your ACS URL, Absorb's Certificate, and know which user property (NameID) you want to send over to Absorb (e.g., if you want to use email as the Id property, you'll need to know which field in your identity provider contains their users' emails). |
Configure Absorb |
You will need to navigate to Portal Settings > Manage SSO Settings > Add.
|
What are the identity provider's properties? |
Your identity provider will have to provide you with the following details:
|
What are your Issuer & Endpoint URLs? |
|
Which Portal Routes do you want to be associated with the SSO? |
N/A |
Configure your Identity Provider |
Unlike SAML, in Open Id Connect routes are associated with the SSO configuration in the Allowed Callback URLs. Using the:
Formats for each assigned route. |
Configure Absorb |
You will need to navigate to Portal Settings > Manage SSO Settings > Add.
|
Metadata
Metadata is used to transfer information about the parties involved in the SSO connection (both the Idp and PS). Metadata is often provided as an XML file, but it can also be plain text formatted like XML. Typically, metadata is only needed for Outgoing Service Provider Initiated SSO because:
- Absorb does not have a mechanism to upload metadata.
- The system only asks for fields the LMS will require. (for the identity provider, these would be the certificate key, signature type, and login URL)
- Most information (like URLs) is available in our documentation.
- 3rd party applications may require the metadata in XML format, which is why we provide this for Outgoing Service Provider Initiated
Click here to download an example of Absorb Metadata.
Troubleshooting
When you receive an error message, perform a SAML trace to review the associated issue. Many times you will be able to resolve these on your own without Absorb Support.
Please note, these instructions are only for those using SAML SSO. Click here to download an example of Outgoing SAML SSO.
- The Certificate Key - This can be found in the <X509Certificate> tag.
- For incoming SSO this value should be an exact match to the key value set in your Absorb LMS portal.
- For outgoing SSO it should be an exact match to the key value set in your 3rd party system (because it's coming from Absorb). If the key does not match exactly, it can prevent SSO from working.
- The NameID - This can be found in the subject in the <NameID> tag in a SAML trace. This property should match an existing user in Absorb based on the ID Property set in Absorb SSO settings. If the NameID value doesn’t match the ID Property in Absorb, the user will be unable to log in.
- Signature type - This can be found in the <SignatureMethod> Algorithm. Failures due to a mismatch on the Signature type are rare, however, if an error is caused due to the signature type failing to match, this will tend to result in an “invalid Signature” error.
SAML Tracers
Browser | Information |
Chrome |
SAML Chrome Panel. This shows up in Developer Tools. Note: The Dev Tools page needs to be open before you start the SSO process. |
Firefox | SAML Tracer |
Fiddler | Alternative: Some clients use Fiddler to troubleshoot SAML issues. Instructions for Fiddler are available here. |
Comments
Article is closed for comments.