Common Errors & FAQs about SSO

Updated 

Clear your doubts and avoid confusion with the answers of some common mistakes and FAQs about SSO in this article. If you want to understand what Single Sign On is, you can refer to this article for more details.

Common Errors

  1. User not found in our system / User not provisioned: This means that the client successfully authenticated the user on their side and sent them back to Sprinklr to be logged in, but the user they sent to Sprinklr to be logged in does not have a matching account in Sprinklr.  Oftentimes the user does have a valid account in Sprinklr, but the email we have entered is slightly different from the one sent in the assertion.  For example if we had the user enter in Sprinklr as “Elizabeth.Escobar@duke-energy.com”, but the assertion identifies the user as “Elizabeth.Escobar-Fernandes@duke-energy.com”.  In this case we send an assertion by the client for a user “Elizabeth.Escobar-Fernandes@duke-energy.com”, but on the Sprinklr end we have no such user to log them in as, and thus they are denied access.  To fix this error simply update the email in Sprinklr to match what is coming in the assertion. 

  2. Wrong Certificate: Typically for this kind of error you might see an error message mentioning that the signing certificate was invalid.  Oftentimes the client provides us a metadata file with a certificate that does not match the certificate that is actually coming in the assertion.  Fixing this error just requires that you take the certificate that is actually being sent in the assertion, format it as needed, and paste this instead into the certificate in the SSO connection.

  3. Wrong ACS URL: Sometimes the customer will leave out the partner ID, or not change it when moving from pre-prod to prod.  This error must be changed on the client’s end.

  4. Entity ID not found in our system: This typically occurs when there is some confusion about what connection we are setting up where (as we typically set up both test and prod connections).  Fixing this simply requires having a conversation with the customer about which connection we are trying to set up and where, and redoing work accordingly if needed.

FAQs

  1. Can we have email/pass, and SSO users in the same environment?

     Yes.  Immediately after SSO is enabled users can log in via email/pass, or SSO if they have SSO credentials.  For users that have SSO credentials, Sprinklr recommends switching them over to SSO-only login, which would force them to use SSO login to access Sprinklr.  Instructions on how to do that can be found here Switching Users to SSO Login only

    Please take care not to do this for Sprinklr employees or any other individuals that do not have SSO credentials, as this would lock them out of Sprinklr. 

  2. What happens in the case that SSO is down?
    If the client’s SSO is down, any SSO users would be locked out of Sprinklr.  Some of our clients choose to leave 1 - 2 admins with the ability to log in via email/password and in the event that SSO was down those individuals could switch the other users over to email/pass login.  This carries its own risk as it would leave a user with admin privileges able to log in via email/pass.  Ultimately it is the client’s decision to make on whether they’d like to take on the risk for 1 - 2 admins to remain email/pass users to mitigate the risk of their SSO being down.

  3. Can Sprinklr support IDP-initiated SSO?

    • For Web both SP and IDP are supported

    • For Mobile only SP-initiated is supported

  4. Is our current SSO integration an open authentication or closed authentication (Private or Public)? 

    • Sprinklr supports Open ID or SAML 2.0 SSO configuration. In our experience most SSO configurations are SAML. Our SAML config uses a Public certificate, which can be found in the metadata provided in the SSO Checklist

  5. Does Sprinklr check for Authorization for the users onboarding?

    • Sprinklr does not support this via SSO. Users must be added manually to Sprinklr with their credentials matching that of what the SSO configuration is sending.

  6. Can a customer have multiple SSOs?

    • Yes, the customer can have multiple SSOs for a single environment for different sets of users.

  7. Does SSO and Mobile Configuration work together?

    • When SSO is enabled for a Sprinklr environment it is also enabled on the mobile interface and users would see their ability to log in via the mobile app, just as they would through a web browser.

  8. Do we have a self-signed Certificate?

    • Yes, by default, we use a self-signed certificate

      • This certificate is valid until 2115

    • If the regulation requires a CA (Certificate Authority) signed certificate, then submit a ticket to Support

      • This certificate is typically valid for 1 - 2 years

      • This does require the Customer to reach out to Sprinklr PRIOR to the certificate expiration date to have this renewed, otherwise this could inhibit their ability to log into Sprinklr