Single sign-on failed attempts

Integrations > Single Sign-on > Inbound SSO > Failed Attempts

This screen lists any failed single Single sign-on (SSO) attempts; when there have been no failures, the screen reports No failed attempts recorded. Use this screen to debug SSO issues. For information about setting up SSO, see Single sign-on (SSO).

Each failed sign-on event lists:

  • Timestamp when the event happened.

  • Failure message (some are described below); click the message link to see details about the request and assertion.

  • SSO mechanism where the failure occurred; matches the AutoLogon Type value on the Single sign-on screen.

    Note: The Single sign-on screen is in transition and can be called Service Provider Config screen on your instance, when you see this screen, AutoLogon Types SAML 2.0 and OIDC are enabled by default.

Following are common failure messages, and descriptions of their cause and resolution:

Important: When the user attempts to connect with a URL that links to a page in the site, that information is passed to the IdP which then passes it back to Medallia Web reporting, which uses it to open the intended page. If the user is being sent to the home page instead of the intended page, the IdP has not configured support for the RelayState parameter. For information about this situation, see SAML 2.0, review SAML 2.0 Profiles and look for the section titled Redirect to IdP SSO Service.

* not found in the SAML Assertion audience

The value for the SP Issuer in the <audience> section of the SAML response does not match what is configured in the Single sign-on screen. It is OK if the client (IdP) sends multiple audiences as long as one matches.

Resolution: Let the IdP know what the value of the SP Issuer the instance is expecting and work with them to ensure it is included in the <audience> section of the assertion.

Could not create the Authentication request

An unexpected error occurred when generating the request to send to the IdP.

Resolution: Contact Medallia Support.

Invalid assertion issuer

The IdP Issuer in the SAML response does not match what is configured the IdP Issuer property on the Single sign-on screen.

Resolution: Review the IdP Issuer in the SAML response and ensure it matches what is configured on the setup screen.

SAML Assertion expired

The assertion happened outside the window of time when it was valid. When the window is in the past or in the future, the assertion is not valid and is expired.

Note: This is not related to expiration or session timeout settings on the setup screen.

Resolution: Review the SAML result and verify the timestamp of the failed attempt is withing the window defined in the <Conditions> node of the assertion, which looks similar to this: 

...
</Subject>
<Conditions NotBefore="2017-07-07T18:57:24.8898114Z" 
            NotOnOrAfter="2017-07-07T19:02:24.8898114Z">
<AudienceRestriction>
...

The timestamp of the attempt must fall between the NotBefore and NotOnOrAfter timestamps. If this is not the case, this can happen because:

  • The time window is too small (such as 5 seconds) and there was a delay in sending the assertion. If this is the case, the client should re-configure the IdP window to be longer. Most configurations use from 2 minutes up to 1 hour.

  • Either the client's server or our server's clock is not synched to universal time. Inform the client that this may be the cause and work with them and the Medallia Operations team to debug further.

Tip: A good rule-of-thumb is to set NotBefore to 2-5 minutes before the actual authentication- time, and NotOnOrAfter to 2-5 minutes after the authentication-time. Whether to use 2 or 5, or some value in between depends in the comfort level of the company.

SAML Assertion processing failed

Either no assertion was found, the assertion was encrypted (and the system was not configured to accept encrypted assertions), or something else unknown and unexpected went wrong. Use secure communications, which requires encrypted assertions.

Resolution: The IdP needs to ensure they are passing a valid assertion. If a valid assertion is being received and it is encrypted, verify Experience Cloud is configured to decrypt the assertion by enabling either the Support encrypted assertions in response or Process encrypted assertions in SAML Response (when using Multiple IDPs).

SAML Assertion signature is not valid

The signature in either the response or assertion is not valid with the IdP certificate configured in the Single sign-on screen. The IdP may be signing the assertion with a different certificate than what is configured.

Note: To support multiple certificates, separate them with a semi-colon (;) on the setup screen.

Resolution: Review the certificate in the SAML response and ensure it matches what is configured on the setup screen.

SAML Assertion signature not found

Either the SAML response or the assertion were not signed. When using secure communication, both the SAML response and the assertion must be signed. The SAML XML will contain a <signature> element when it is signed.

Resolution: Work with the company and the IdP setup secure communication between the Experience Cloud instance and the IdP. See Single sign-on (SSO) for information about setting up secure communications. Medallia recommends using secure communications. 

SAML Authentication failed

The user account was not authenticated or authorized by the IdP. This is indicated by an attribute in the <statuscode> element in the SAML response: it should include status:Success at the end of the value.

<sampl2:status>
   <sampl2:statuscode value="urn:oasis:names:tc:SAML:2.0:status:Success"</sampl2:statuscode>
</sampl2:status>

Resolution: The user needs to reach out to their company and IdP to determine why the account could not be authenticated.

There were issues while processing the SAML permission attributes. Please contact your administrator

This happens during an Auto Importer session, most often when creating an account where the account information in the assertion does not have a primary role.

Resolution: Review the Debug info in the failed attempt for a more detailed information about why the the auto importer failed. Review the incoming attributes in the SAML response and update the auto importer specification to fix the issue. The import specification should be in CREATE_AND_UPDATE mode to allow creation of the account. Confirm the issue was fixed by uploading the SAML response in pretend-mode on the auto importer.