Introduction
This article contains information about common errors and messages that you may encounter when implementing Incoming SAML Single-Sign-On (SSO) with Absorb LMS.
Table of Contents
- Common SSO Configuration Errors
- HTTP Code: 200
- HTTP Code: 302
- HTTP Code: 403
- SSO Deep Linking: IDP Relay State
- Developer Tools Error
- SAML SSO Support
Common SSO Configuration Errors
Error | Details |
---|---|
Key (X509 |
Make sure that there are no line breaks or spaces in the key when it is entered to Absorb; this should exactly match what is in the SAML Response. |
Id Property |
This must match what your identity provider is sending as the NameId value in the SAML Response to match to a user in the LMS using the Id Property as defined in your SSO configuration settings within Absorb. |
Consumer Assertion/ACS URL |
This URL should follow the format [https://company.myabsorb.com/api/rest/v2/authentication/saml] |
Assigned Route |
A route must be assigned to the SSO configuration in the LMS; otherwise, the SSO configuration will not activate. |
Relay States |
For Identity Provider Initiated configurations, if relay states are desired, this option must be enabled through your SSO provider, or they will be ignored upon successful authentication. |
HTTP Code: 200
200: Multiple Users
HTTP Code: 200 - Multiple Users | |
---|---|
Error |
Absorb Dashboard Message: "We apologize; multiple users were found matching the NameID assertion." Example: https://PortalURL.myabsorb.com/#/sso-error?ssoError=SamlMultipleUsersFound" |
Explanation |
When clicking the Absorb LMS app in the SSO portal, the user receives the above message. |
Solution | Remove or edit users that have the same unique identifier. In the above issue, there were users with the same email address under Inactive and Active users. |
Error Example |
---|
![]() |
200: Code after Successful Log In
HTTP Code: 200 - 200 after successful login | |
---|---|
Error |
The Login shows as Successful in the Logins table, and the learner is taken to one of the following error pages:
However, a grey screen is seen with three dots, and the page never loads. |
Explanation |
The Single Logout URL is invalid in the SSO Settings. |
Solution |
The Logout URL must begin with https:// |
200: Invalid or Not Found Credentials
HTTP Code: 200 -Invalid or not found credentials | |
---|---|
Error
|
Absorb Dashboard Message: Invalid or not found credentials Example: https://portal.myabsorb.com/#/sso-error?ssoError=CredentialsInvalidOrNotFound |
Explanation | The user attempting to log in is Inactive in the LMS. |
Solution | The user must be Active in the LMS for them to successfully log in. |
HTTP Code: 302
302: No Matching User Found or There was an Error with Username
HTTP Code: 302 - No Matching User Found | |
---|---|
Error |
Absorb Login Screen "We apologize; no matching Absorb user was found, or there was an error with the username" Example: https://Company.myabsorb.com/#/sso-error?ssoError=SamlNoUserFound |
Explanation | After Authenticating with the SSO provider, the User selects the App on the SSO portal and is routed to the Absorb dashboard with an error. |
Solution | If user provisioning is DISABLED (Error reads: We apologize; no matching Absorb user was found):
If user provisioning is ENABLED (Error reads: We apologize; there was an error with the username)
|
Explanation |
There are multiple possible causes for this error: A. The Key in the SAML response is encrypted, which is not supported. You will be able to verify this is the cause of the issue if <Encrypted Key> displays in the SAML response. B. The x509 key in the request does not match what's in Absorb. C. The SAML response is being re-used: Some clients have looked to re-use SAML Responses as part of their SSO process through custom SSO configurations. Unfortunately, this will not work as Absorb performs a one-time-use check. D. The timing of the SAML response doesn't fall within the timeframe specified in the SAML response |
Solution |
A. Absorb Does not support Encrypted SAML Responses. In ADFS, Removing the entry under the encryption tab of the ADFS SSO properties for the Absorb connection and moving them to the Signature tab should help, as Absorb does support signed responses. B. Update the signature key in Absorb so that it matches what is being sent in the request by the Identity provider.
C. Avoid SAML responses being re-used. D. Ensure that the correct SAML responses are used and fall within the timeframe specified in the SAML response. E. If Provisioning is to be enabled on the portal, ensure that entries being passed are on a single line of text, within the character limit for that field. |
Explanation |
This error happens when there is a mismatch between the Mode selected in the Absorb SSO Settings and the Login URL entered. If SP-initiated mode is selected, the Login URL should be the IDP endpoint for SAML requests. If IDP-initiated mode is selected, the Login URL should be the user access page. Note: SP-initiated is the recommended setup for incoming SSO. |
Solution | If you are using the recommended Service Provider Initiated SSO:
|
Error Example -Provisioning Disabled | Solution Example - Provisioning Disabled |
---|---|
![]() |
![]() |
302: Response Signature could not be Verified
HTTP Code: 302 - No Matching Absorb User Was Found (Response Signature Error) | |
---|---|
Error |
Absorb Login Screen "We apologize. The Single-Sign-On response signature could not be verified." |
Explanation |
There are multiple possible causes for this error:
|
Solution |
Absorb Does not support Encrypted SAML Responses. Removing the entry under the encryption tab of the ADFS SSO properties for our connection and moving them to the Signature tab should help, as we support signed responses.
Correct <saml:Conditions NotBefore="2021-06-09T22:19:54.650439+00:00" NotOnOrAfter="2021-06-09T22:20:24.650470+00:00"/><saml:AuthnStatement AuthnInstant="2021-06-09T22:19:54.650439+00:00">
Incorrect <saml:Conditions NotBefore=\"2021-06-08T12:21:53.682Z\" NotOnOrAfter=\"2021-06-08T12:26:53.682Z\" /> |
Error Example |
---|
![]() |
Solution Example | |
---|---|
![]() |
![]() |
HTTP Code: 400
HTTP Code 400: "...not a valid SAML 2.0 protocol"
HTTP Code: 400 - Not a Valid SAML 2.0 Protocol |
|
---|---|
Error |
The User receives an error advising SAML request is not valid/must be present. "The request is not a valid SAML 2.0 protocol" OR "SAMLRequest or SAMLResponse must be present as query string parameters in the HTTP request for SAML Redirect binding" message. |
Explanation |
This error happens when the wrong login URL is applied in the SSO settings in Absorb on an IdP initiated SSO set up (e.g. with Microsoft Azure or ADFS). The login URL should not be a SAML request URL, just the URL of a page where someone can log in. If the client wants the SSO to know who the user is, then they need SP initiated. |
Solution |
If Service Provider Initiated mode is used:
If Identity Provider Initiated mode is used:
|
Error Example |
---|
![]() |
HTTP Code: 403
HTTP Code: 403 | |
---|---|
Error |
Upon putting in the Username and Password for SSO Login, the following error occurs.
Alternate error language may present: |
Explanation |
The route assigned to the SAML Consumer URL within the SSO provider did not match the URL assigned to "Assigned Route" in Absorb SSO Setup. |
Solution | Update the Consumer URL in the SSO Provider. |
Note: Right-Click on the images to enlarge and open in a new browser window/tab.
Error Example | Solution Example |
---|---|
![]() |
![]() |
SSO Deep Linking: IDP Relay State
SSO Deep Linking: IDP Relay State | |
---|---|
Error |
When using a deep link, the user is asked to authenticate through the client SSO login page and then transported to the dashboard, not the deep-linked area. |
Explanation |
IDP Mode does not retain the relay state when transporting a user through SSO. |
Solution |
While Deep linking can be used with an IdP initiated SSO, it requires the use of a relay state set up by the client in order to retain the deep linked page when a user logs in through a deep link. As well Switching to using SP Initiated over IdP initiated would eliminate this need and is generally the recommended approach. |
SAML SSO Support
Disclaimer: Absorb LMS supports SAML 2.0 Single Sign-On as a feature; however, we do not officially support any specific client-side (IdP) solution. Although many platforms generally work with our implementation of SAML SSO, it is the client's responsibility to configure/develop, and maintain their side of the integration. Your team will require a resource who is knowledgeable and familiar with your specific SSO instance.
Please include a SAML trace of your login attempt when submitting a support ticket for SSO-related issues to expedite resolution.
SAML Trace: Google Chrome
A good option is the SAML Chrome Panel extension which appears in the Chrome Developer Tools once installed.
1. Press F12 to start the developer console.
2. Select the SAML tab.
3. Reproduce the issue.
4. Click the Export button to download the report:
SAML Trace: Firefox
The Firefox add-on SAML Tracer can prove helpful.
1. Click on the SAML-tracer icon in your browser window:
2. Reproduce the issue.
3. Look for an orange SAML label in the table to ensure the SAML transaction was captured.
4. Click Export:
Provisioning Errors
If the SAML authentication is verified but the user does not exist in the LMS, provisioning will be attempted. However, issues provisioning the user will result in an error describing the user provisioning issue:
- Notification that the there was an issue creating their account
- Information on the attributes that resulted in a failure to provision the user (if applicable)
An error will occur and the user will not be provisioned if:
-
Mandatory user fields for an LMS profile are missing or invalid
- Mandatory fields include username, first name, last name, and department.
- Fields set as required in the portal's user profile and custom field settings can be overridden by an administrator as desired. As such, these fields are not treated as mandatory for account provisioning.
-
Attribute statement does not include the Id property used in the authentication stage
- In addition to the mandatory fields listed above, the Id property used in the authentication stage is also mandatory. For example, if SSO attempts to authenticate using email address, an "Email" attribute must be present for the provisioned user to ensure that the next time they authenticate there is a value present to match on, otherwise provisioned accounts would be orphaned the next time the user attempts to authenticate.
-
The Id property's value in the attribute statement does not match the NameId's value in the authentication statement
- Further to above, Absorb also requires that the value passed in the NameId (used in the authentication stage) matches the value included in the attribute for the Id property in the provisioning stage. For example, if SSO attempts to authenticate on email address, the "Email" attribute must contain the same value as the NameId value used for authentication, otherwise provisioned accounts would be orphaned the next time the user attempts to authenticate.
-
The username included in the attribute statement already exists in your Absorb portal
- This error is only possible if the Id property set in your SSO config is NOT username (e.g. email, external Id, or Absorb Id); if that value does not exist in Absorb, a user provisioning attempt is made, but if the username specified for the new user already exists, another user with that username will not be created.
-
Attribute statement includes an attribute value that fails to meet the minimum restrictions imposed on the field(s)
- Please see the Default Fields and Custom Fields sub-sections below for accepted attribute values
- e.g. ProvinceCode is provided but CountryCode is not provided
- e.g. ProvinceCode does not belong to the provided country
- e.g. CountryCode or ProvinceCode are provided but do not match a supported country or province code or format. At the time of writing, Absorb LMS supports the majority of ISO 3166-2 alpha-2 province codes. In cases where a country's divisions directly overlap with a set of sub-divisions, Absorb has opted to support at a minimum the lowest-level sub-division for the region and may not support all official regional councils, administrative divisions, territorial collectivizes, etc. Please review existing LMS country/province dropdowns to view all supported countries and their respective sub-divisions.
Specific Error Messages
Error Message |
Potential Cause(s) |
No matching Absorb user was found. |
|
We were unable to provision a user. |
|
We were unable to provision a user. There was a problem with 'Username'. |
|
We were unable to provision a user. There was a problem with 'Email'. |
|
We were unable to provision a user. There was a problem with 'EmployeeNumber'. |
|
We were unable to provision a user. There was a problem with 'UserExternalId'. |
|
We were unable to provision a user. There was a problem with 'Gender'. |
|
We were unable to provision a user. There was a problem with 'DateHired'. |
|
We were unable to provision a user. There was a problem with 'Department Id'. |
|
We were unable to provision a user. There was a problem with 'ExternalDepartmentId'. |
|
We were unable to provision a user. There was a problem with 'CustomFields'. |
|
We were unable to provision a user. There was a problem with 'FirstName'. |
|
We were unable to provision a user. There was a problem with 'LastName'. |
|
We were unable to provision a user. There was a problem with 'Address'. |
|
We were unable to provision a user. There was a problem with 'Address2'. |
|
We were unable to provision a user. There was a problem with 'City'. |
|
We were unable to provision a user. There was a problem with 'CountryCode'. |
|
We were unable to provision a user. There was a problem with 'JobTitle'. |
|
We were unable to provision a user. There was a problem with 'LanguageCode'. |
|
We were unable to provision a user. There was a problem with 'Location'. |
|
We were unable to provision a user. There was a problem with 'MiddleName'. |
|
We were unable to provision a user. There was a problem with 'Phone'. |
|
We were unable to provision a user. There was a problem with 'PostalCode'. |
|
We were unable to provision a user. There was a problem with 'ProvinceCode'. |
|
We were unable to provision a user. There was a problem with 'SupervisorIdentifier'. |
|
Response Signature could not be Verified |
|
For more information about provisioning, you can refer to the Incoming SAML 2.0 SSO Account Provisioning article.
Comments
Article is closed for comments.