Troubleshooting Incoming SAML SSO



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

Error Details

X509 Certificate

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 []

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

Absorb Dashboard Message: "We apologize; multiple users were found matching the NameID assertion."



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

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.


The Single Logout URL is invalid in the SSO Settings.


The Logout URL must begin with https://


HTTP Code: 302

302: No Matching User Found

HTTP Code: 302 - No Matching User Found

Absorb Login Screen "We apologize; no matching Absorb user was found."


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
  • If the user doesn't exist in the LMS, create the account. 
  • If the user already exists in the LMS, change the ID Property in the Absorb side configuration to match your Identify Providers in the Name ID Property of the SAML Response.

If user provisioning is ENABLED:

This error is generic and can mean any of the following:

  • The following required fields (Username, FirstName, LastName, Department, etc.) are used as the ID Property.
      • Example: The ID Property is not a username; however, the username requested is not available.
      • Example: The ID Property is an email address. There isn't a User with that ID Property, but there is a user with the exact email address as their Username.
      • Example: The ID Property is not the Username, and there are multiple matches for the ID Property.
      • Attributes are Case Sensitive; ensure that the claims are in the correct format. (ie INCORRECT = "nameid" will error, CORRECT = "NameID")
      • ExternalDepartmentID cannot contain special characters: . _@%$&


Error Example -Provisioning Disabled  Solution Example  - Provisioning Disabled 
Error-302-No-User-Found-Example.png Solution-302-Provision-Disabled.png


302: Response Signature could not be Verified

HTTP Code: 302 -  No Matching Absorb User Was Found (Response Signature Error)

Absorb Login Screen "We apologize. The Single-Sign-On response signature could not be verified." 


There are multiple possible causes for this error:

  • This message appears after entering credentials/authenticating on the remote site/system. You will be able to tell this error comes from others because, in SAML Tracer, you'll see it trying to send a <EncryptedKey> field.
  • Everything in the request looks correct; however, the x509 key in the request does not match what's in Absorb.
  • The SAML response is being re-used. Absorb performs a one-time-use check.
  • The timing of the SAML response doesn't fall within the timeframe specified in the SAML response.

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. 

  • Updating the signature key in Absorb so that it matches what is being sent in the request by the SSO.
  • Ensure that the Key field in your LMS SSO settings contains no spaces or other characters that do not match what is sent in the response.
  • Avoid SAML responses being re-used.
  • Ensure that the correct SAML responses are used and fall within the timeframe specified in the SAML response.


<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">



<saml:Conditions NotBefore=\"2021-06-08T12:21:53.682Z\" NotOnOrAfter=\"2021-06-08T12:26:53.682Z\" />
<saml:AuthnStatement AuthnInstant=\"2021-06-08T19:21:53.682Z\">


Error Example


Solution Example 
302-Signature.png 302-Signature-ADFS MGMT.png


HTTP Code: 400

HTTP Code 400: "...not a valid SAML 2.0 protocol"

HTTP Code: 400 - Not a Valid SAML 2.0 Protocol


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.


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.


If Service Provider Initiated mode is used: 

  • Change the Mode field in the LMS SSO settings to Service Provider Initiated.

If Identity Provider Initiated mode is used: 

  • Correct the Login URL field to the identity provider's access URL. For Azure, this is the User Access URL (not Azure's Login URL), the correct URL looks similar to:[someid]


Error Example


HTTP Code: 403

HTTP Code: 403

Upon putting in the Username and Password for SSO Login, the following error occurs. 

  • Click on the Absorb App inside the SSO portal; the link is broken and goes to an error page.
  • "Validation 403 Sign-On Request not permitted Site can't be reached."
  • "Single Sign-On Requests are not permitted."

Alternate error language may present:
SAMLRequest or SAMLResponse must be present as query string parameters in an HTTP request for SAML Redirect binding.


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
error-403.png Solution-403-Highlight.jpg


 SSO Deep Linking: IDP Relay State

SSO Deep Linking: IDP Relay State

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.


IDP Mode does not retain the relay state when transporting a user through SSO.

Detailed instructions for Deeplinking


Change the SSO mode to SP Initiated.  

Note: this may require changes to the settings within your IDP setup and changing the Login URL in Absorb.



Developer Tools Error

"SAMLRequest IssueInstant too old to trust"

"SAMLRequest IssueInstant too old to trust"

An error of "SAMLRequest IssueInstant too old to trust" is presented when observing errors via the browser's Developer Tools.


This is an error that can be observed in association with SAML SSO. More commonly with Service Provider Initiated configurations.

  • This issue will be observed by opening the developer tools and observing an error event attempting to connect to the IdP.
  • It can additionally be captured by performing a SAML trace and observing the SAML authentication request.

The IdP server is out of sync with system clocks. Thus the IdP server appears to be "in the past" or "in the future." This means the SAML authorization will appear out of   Syncing the IdP server with system clocks should clear this issue.

The IdP server is preserving outdated cache. This can represent an old certificate, an old token, or something similar. Refreshing the cache of the IdP server can resolve this issue.


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:  


Published on
Have more questions? Submit a request


Article is closed for comments.