Testing SSO

Following are some of the common ways to test and verify SSO is working. To debug SSO problems, see Single sign-on failed attempts for descriptions of common problems and how to resolve them.

Verify single sign-on is turned on

Verify the Autologon Enabled is on.

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, the AutoLogon option is enabled by default

Verify internal and external networks

Have the company team verify they can connect via SSO from both their internal and an external network. Certificates can be misconfigured to a work on internal networks only, but will fail on external networks.

Connect to the SSO instance

Access the SSO instance using a URL nearly identical to the one for non-SSO access, the only difference is the inclusion of "sso/" before the company ID.

https://INSTANCE.medallia.com/sso/COMPANY/...

Verify the IdP service is correct

A common configuration error happens when the instance is configured to use SP-initiated sessions, but is calling a service on the IdP that handles IP-initiated sessions. For web sessions, the misconfiguration is not always obvious, but for mobile sessions, the app is not able to connect properly.

For SP-initiated sessions, the Experience Cloud instance redirects the user to the IdP sign-in when the user is not already authorized. After the user signs in to the IdP, the IdP redirects the user back the company instance. If the user accessed the instance using a deep link, the user is directed to the screen in the URL. For example, to go straight to the Response reports like this (often used in emails):

https://example.medallia.com/sso/company/respInv.do?...

However, for IdP-initiated sessions, the IdP always redirects the user to a specific URL that is the same location every time. When an instance configured for SP-initiated sessions calls the IdP service for IP-initiated sessions, the IdP always redirects to the user to the predefined URL, which is typically the default dashboard.

To verify the configuration is using the correct service:

  1. Sign in to the instance using an account that can access reports.

  2. Open a report and copy the path of the report; omit the portion of the URL after the ".do".

    Copy URL to https://example.medallia.com/company/respInv.do

  3. Sign out of the session.

  4. Ensure you are not already authorized by the IdP for the browser you are using. Some ways to do that are:

    • Use a "private" or "incognito" browser window: these will not have the existing authorization information (if any) and will require an IdP sign-in

    • Clear the browser's cookies for medallia.com

    • Go to the IdP and sign-out

  5. Paste the URL into a new browser tab, and insert "sso/" to initiate single sign-on.

    Enter URL to https://example.medallia.com/sso/company/respInv.do

  6. The browser should be redirected to the IdP to require the user to sign-in.

    If not redirected to the IdP screen, go back to step 4 and sign-out of the IdP.

  7. After signing in to the IdP, the IdP redirects the browser to the instance.

If the browser does not open the target report, and instead opens another, such as the Home dashboard, it is because the IdP is not returning the proper information for SP-initiated sessions in the assertion. To correct this problem:

  • Verify with the IdP the URL in the IdP Request Service URL is the one for SP-initiated sessions.

  • Look at the SAML assertion and verify the RelayState element has a value in both the request and the assertion. This element contains the information the instance needs to identify the target screen.

Verify the claim represents the account username

When debugging OIDC SSO connections, if you only receive the id_token in the SSO response:

  1. In the Failed Attempts screen, copy the code after id_token.

  2. Go to https://jwt.io/.

  3. Paste the token into the Encoded text box and wait a few seconds.

  4. Read the full payload in the Decoded text box and look for something that can be used to identify a user (email or preferred_username for instance).

  5. Change the Claim name to map user property to reference the attribute name from step 4.