Troubleshooting SSO issues

Find solutions to your issues with configuring or logging in with SAML SSO.

Courtney Leacock avatar
Written by Courtney Leacock
Updated over a week ago

This article will help you troubleshoot issues with your Single Sign On setup.


Why do users have to enter their email address when logging in with SAML SSO?

The admin user login page is centralised and not specific to your company account. Users have to enter their email address at the start of a SAML SSO login so we can find their company account.

Email entry is not required on the End User Portal as those login pages are specific to your company account. This means our SAML SSO solution can look up your configuration directly in order to connect with your identity provider.

Why doesn’t the SAML test utility in my identity provider work?

The platform generates a pre-authentication token as part of the SAML SSO authentication process. This will not be present when an identity provider’s SAML test utility is used so the platform will show an error screen. This is because the platform cannot verify the company account for the SAML SSO authentication attempt.

You will have to test the SAML SSO integration by logging into the platform.

Is the ACS URL correct?

The Assertion Consumer Service (ACS) URL is the URL the SAML SSO identity provider will use to send a response to our platform. SAML SSO authentication responses will not reach the platform If the ACS URL configured in your identity provider is incorrect. Users will not be redirected back to the platform after the identity provider part of the process when this is the case.

Please confirm that the ACS URL in the platform’s SSO settings and your identity provider’s SAML SSO configuration match. The ACS URL will change if your Preferred Domain setting in the platform is updated.

Is the Entity Id correct?

The Entity ID identifies the platform as a SAML service provider. It is included in the SAML request URLs that redirect users from the platform’s login page to your identity provider. If it is incorrect, your identity provider will reject the request as the service provider (i.e. the platform) is not recognised.

Please confirm that the Entity ID in the platform’s SSO settings and your identity provider’s SAML SSO configuration match. The Entity ID will change if your Preferred Domain setting in the platform is updated.

Is the SAML Entry Point URL correct?

The SAML Entry Point (or Identity Provider SSO URL) is used to construct the SAML request URLs that redirect users from the platform’s login page to your identity provider. If it is incorrect, users will not be redirected to your identity provider and SAML SSO will not be possible.

Please confirm that the SAML Entry Point in the platform’s SSO settings matches the one in your identity provider’s SAML SSO configuration.

Is your SAML Signing certificate correct or has it expired?

The SAML Signing Certificate (or Public x509 Certificate) is used to sign the SAML request URLs that redirect users from the platform’s login page to your identity provider. If the signature cannot be verified then your identity provider will reject the request.

If in doubt you should go into the platform’s SSO Settings and replace the certificate with the current one from your identity provider’s SAML SSO configuration. You can also see the fingerprint of the current certificate which you can use to verify if the certificate present matches the one in your identity provider. Not all providers make this fingerprint visible which is why we advise to replace the certificate in the platform instead.

These certificates do have an expiry date so you may find that SAML SSO stops working because the certificate in place has expired. It is best practice to monitor the expiry date of your SAML certificates and replace them ahead of time. Otherwise you could be locked out of the system if you only allow SSO authentication for admin users on the platform.

Are users assigned to the SAML SSO integration in your identity provider?

Any user who wishes to log in to the platform using SAML SSO will need to be assigned to the integration on the identity provider side.

Most identity providers will include a user assignment option either during setup or as an administrative feature. Setting up a SAML SSO integration will include a user assignment step. That should allow you to specify the user who can authenticate on the corresponding service provider i.e. this platform. Your assigned users should match the platform’s user base as closely as possible. For example, if you use one of sync integration to import end users then your SAML SSO user assignments should pull in the same groups.

Do the users experiencing SAML SSO issues have accounts on the platform?

The SAML SSO authentication process matches identity provider and platform user accounts by email address. This feature does not support user provisioning of any kind so user accounts will not be created in response to successful SAML authentication. Users who need to authenticate using SAML SSO will require admin and/or end user accounts on the platform to access the admin console and/or end user portal respectively.

I'm seeing the error code AADSTS75011 when attempting to login via Microsoft Entra

Some configurations of Microsoft Entra require the RequestedAuthnContext attribute be removed from the SAML request. You can achieve this by updating your SSO settings in usecure platform:

  1. Navigate to Settings > SSO in your usecure portal.

  2. Scroll down to the "Advanced Options" section and expand the box

  3. Make sure Disable RequestedAuthnContext is toggled on

  4. Save your settings and attempt to login again

I'm seeing the error code SAML-RE-UE

This error code is caused by an invalid signing certificate, and is often resolved by re-uploading for signing certificate. This can be done by navigating to Settings > SSO in your usecure portal and clicking the Replace Certificate button.

My configuration looks correct but there are still login issues

This typically means that you may have misconfigured the SAML setup on your identity provider outside of the option documented in our setup guides. For example, our solution relies on the Relay State returned by your identity provider. If you’ve set any options that disrupt the Relay State, the pre-authentication token we send as part of the SAML SSO authentication process may be lost or modified which will break our verification process.

You may find that users cannot login despite a successful login on their identity provider account. The pre-authentication tokens we issue during an SAML SSO login expire after a short period of time. If a user does not complete the full SAML SSO login process in that time they will need to try again. Subsequent attempts should be quicker as the user is logged into their identity provider already at this point.

When reporting SAML SSO issues to support please provide the following information:

  • Where the user was logging in from i.e. admin console or end user portal

  • An account of what the user did

  • The identity provider used e.g. Microsoft 365/Azure/Entra, Google Workspace

  • Browser & OS used

  • Screenshots or text of any errors returned including the error code in square brackets.

  • The full URL in the browser when the error occurred

What does this SAML error message mean when using Google Workspace as an identity provider?

If you use Google Workspace as an identity provider, your users may see a Google error screen if SAML SSO authentication fails. This typically indicates an issue with the custom SAML app you created in Google Workspace for this integration. You can find a full list of Google SAML app error messages here along with possible solutions for the underlying issues.

Did this answer your question?