SAML 2.0 errors and fixes

A list of common errors and associated fixes after you activate the SAML 2.0 plugin and configure the SAML 2.0 integration.

Table 1. Errors during SAML 2.0 setup
Error in instance logs Corresponding SAML property Fix
NotAfter: <Thu Jun 05 22:57:44 PDT 2014>. N/A Update the SAML 2.0 certificate record.

The current certificate has expired. The instance does have the option to send a notification when a certificate is nearing expiration.

Unable to locate SAML 2.0 certificate.

or

Could not find a digital signature stored in the ServiceNow instance.

The PEM-formatted string should be entered into the PEM Certificate field.
  • Ensure that the correct PEM-formatted certificate is uploaded to the instance.
  • Verify that the certificate has the name SAML 2.0. No other names are allowed.
Certificates don't match. Expect: <certStr>, actual: <inboundCert>. N/A Confirm that the PEM-formatted string in the SAML 2.0 certificate record matches the X509 Certificate in the SAMLResponse for the user IdP.
Typical causes:
  • The certificate is updated on IdP but not in the ServiceNow instance.
  • The certificate is in the wrong format.
Failed to check the validity of the certificate. N/A Update the SAML 2.0 certificate record.

The current certificate has expired.

Failed to validate signature profile. N/A IdP admin: Confirm that the SAML certificate on the instance is the correct one to use.
InResponseTo attribute in SubjectConfirmationData mismatch. Expect: <inResponseTo>, actual: <inResponseTo>. N/A IdP admin: Confirm that the expected SAMLReponse is being returned.
The error appears if either of the following situations occurs:
  • The IdP returns a SAMLResponse for a different SAMLRequest
  • A user bookmarks the URL with the SAMLRequest instead of just the instance URL
.
SessionIndex value not found: <message>... N/A IdP admin: Confirm that the SessionIndex is defined in the SAMLResponse.
No valid SubjectConfirmation found. N/A Review SAMLResponse to determine if Conditions is included in the SAMLResponse.

Conditions could be missing due to an error on the IdP. The StatusCode in the response would contain Responder instead of the expected Success.

Assertion audience mismatch. Expect: <propAudience>, actual: <audienceUri>.

or

AudienceRestriction validation failed. No matching audience found.

The audience URI that accepts the SAML2 token. (Normally, it is your instance URI. For example: https://demo.service-now.com.) Locate <saml2:Audience> in SAMLResponse in the logs and verify that the value matches the one on the instance.

The value for this property is usually the instance URL, however, the addition or missing / can cause issues.

Assertion issuer is invalid. Expect: <value on instance>, actual: <value returned by IdP> The Identity Provider URL which will issue the SAML2 security token with user info. Confirm that the SAML property (the Identity Provider URL which will issue the SAML2 security token with user info) is set correctly. See the following error message: Script: SAML2ValidationError: Assertion issuer is invalid. Expect: <value on instance>, actual: <value returned by IdP>.

Typically, the value is a URL, but OKTA and other IdPs can be configured to return an application ID.

Subject is valid in the future. Now: <now>, NotBefore: <notBefore>

or

Subject is expired. Now: <now>, NotOnOrAfter: <notOnOrAfter>

The number in seconds before notBefore constraint, or after notOnOrAfter constraint, to consider still valid. Update the SAML property glide.authenticate.sso.saml2.clockskew to a larger value.

Default of 60 seconds. Some cases require a setting of 300 or higher. You may also need to check the time on your IdP server.

Assertion is valid in the future, now: <now>, notBefore: <notBefore>

or

Assertion is expired, now: <now>, notOnOrAfter: <notOnOrAfter>

The number in seconds before notBefore constraint, or after notOnOrAfter constraint, to consider still valid. Update the SAML property to a larger value.

Default of 60 seconds. Some cases require a setting of 300 or higher. You may also need to check the time on your IdP server.

Table 2. Login errors
Error or symptom Fix
Authentication fails and the login request generates an infinite loop between the system and the IdP. Set (or create) the system property glide.authenticate.failed_redirect to redirect failed authentication requests to this URL. Typically the URL endpoint is an error page or logout page.
Login requests generate an infinite loop between the system and the IdP when High Security is active. Disable the rotating session feature when using SAML 2.0 for authentication.

The rotating session feature of the High Security plugin can cause problems with the SAML 2.0 authentication process. SAML 2.0 needs to redirect URLs to an IdP. When rotating sessions are enabled, any redirection causes the session to rotate and forces the instance to query the IdP again. This causes an endless loop of new sessions between the instance and the IdP.

Table 3. IdP errors
Error reported in IdP logs IdP Fix
The token that was used to authenticate the user or the request is signed with the signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 which is not the expected signature algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1. Check the Alert Context tab for event details. ADFS
  1. Navigate to the Advanced tab of the Relying Party Trust configuration dialog.
  2. Verify that the algorithm is set to SHA-1 and not SHA-256.