SAML 2.0 SSO

Updated 

Single Sign-On capability provides the end users an easier way to login compared to the email/password login method. Users can log in to the Sprinklr platform via their company’s enterprise login only, with just a click. 

For example, for a user, who is logged into their brand’s employee portal, once the SSO setup is done for the brand then this user will be able to directly log in to Sprinklr. Login will happen via the brand's identity provider directly and no separate username and password needs to be created for logging in to Sprinklr 

Benefits of Using SSO Login

  • Adds convenience for the customer: Fewer logins that they need to create and remember 

  • Increases security:  

    • Any individual leaving the company will lose Sprinklr access as well.  

    • This would result in any security measures built into the customer’s login such as two-factor authentication, being on an internal network, etc., applied to Sprinklr login as well 

Here is a sample screenshot of what the client will see when SSO is enabled, which will vary for each implementation:  

How does SSO work? 

There are two parties involved in a SSO login: 

  • IDP: Identity Provider where the user’s identity is stored. Eg: Microsoft Azure 
    An IDP is a service that maintains and manages digital identities to verify user credentials throughout applications, networks, and web services. Its primary role is to safeguard the integrity of user credentials and federate user identity where SSO logins are desired. 

  • SP/Client: Service Provider (The application users want to access). Eg: Sprinklr platform 
    Service providers are a resource that users authenticate into using SSO, usually a private website or application. They receive, accept, or deny assertions (in case of SAML 2.0) & ID tokens (in case of OIDC) from IDPs for each client profile prior to granting users access. 

The IDP has the information of the various SPs/Clients and vice versa. The architecture is a handshake protocol. Sprinklr validates the information and only then allows the user to be logged in. 

​What information is required for the Customer to register Sprinklr in their IDP for SAML 2.0 SSO? 

​Before configuring SSO on the Sprinklr platform, there are some steps that need to be performed on the Identity Provider side for beginning the process. The steps to obtain the information needed to be shared with the client from Sprinklr for setting up SSO details on the IDP end are mentioned in this article below.

Information to be Shared from Sprinklr

  • Service provider (Sprinklr in this case) details including:

    • Service Provider Login URL: https://{prefix-of-domain}.sprinklr.com.   

      The naming convention is https://x.sprinklr.com for the production and https://staging-x.sprinklr.com for staging (testing process), where x is the name of Client. e.g., https://wellsfargo.sprinklr.com and https://staging-wellsfargo.sprinklr.com

      Note that the domain needs to be set by the ITOPs.

    • Entity ID from Sprinklr: Usually it is https://saml.sprinklr.com for all environments, including app, prod0, and prod2. Note: You cannot use the same Entity ID twice for a client who wants two SSO configurations in the same environment as it is a unique identifier in the environment’s SSO configurations.

    • ACS URL : https://{prefix-of-domain}.sprinklr.com/ui/sso/saml/{partnerId}

      • The naming convention is https://x.sprinklr.com/ui/sso/saml/{partnerId} for the production and https://staging-x.sprinklr.com/ui/sso/saml/{partnerId} for the staging, where x is the name of the Client. The staging URL should be the custom domain that we can fetch from the backend for any partner.

      • At the end of the ACS URL you will need to enter the partner ID highlighted in red.

  • Public Key Certificate of Sprinklr for SAML. (Certificate Download Link) : https://www.google.com/url?q=https://sprinklr.atlassian.net/wiki/download/attachments/6193306/ssonew.pem?version%3D1%26modificationDate%3D1400568707000%26cacheVersion%3D1%26api%3Dv2&sa=D&source=docs&ust=1671526424742999&usg=AOvVaw0vcawTTd46ZKETfdoRQFwI.

    Note: The above certificate is for staging in the prod0 (partner ID: 9056). This certificate is also mentioned in this mapping sheet.

Steps to Configure SSO on Sprinklr

Once you are done with the basic understanding and gathering necessary details for setting up SSO in your environment, you can proceed with the configuration of SSO on the platform.

Note:

  • After receiving all the necessary details necessary from the Identity Provider, you can proceed with the SSO setup on the staging or Sandbox environment.

  • Once you have received the confirmation of perfect working of staging environment from test users, you can go ahead to the Production environment to configure SSO.

  1. Click the New Tab icon. Under Platform Modules, click All Settings within Listen.

  2. In the Platform Settings window, click Manage Customer in the left pane and select Account Groups in the right pane

Details to be filled on the Sprinklr Settings → SSO Configuration page:

  • Name: Enter the desired name for the SSO

  • Select the Type of Single Sign On: SAML 2.0 or OpenID 


Configuration Steps For SAML 2.0

You can either auto-fill all the configuration fields by importing the XML file provided by the IDP or manually fill-up all the configuration fields. Click Import Metadata to auto-fill the required fields. Refer to the field description below to manually fill-up the fields -

  • Entity ID: Input entity ID from client into Sprinklr.

    • For Metadata file it corresponds to the “entityID=” field

    • For SSO Checklist it corresponds to the “Entity ID of Identity Provider” field

  • Issuer Name: Issuer Name is a URL that uniquely identifies your SAML identity provider.
    SAML assertions sent to Sprinklr must match this value exactly in the attribute of SAML assertions. Issuer Name is an autopopulated field. You can update it based upon your requirements.

  • Identity Provider Login URL: Input the IDP Login URL from the client into Sprinklr.

    • It is the domain to which Sprinklr redirects after logging via SSO.

    • For Metadata file it corresponds to the “<md:SingleSignOnService”, “Location=” field

    • For SSO Checklist it corresponds to the “Identity Provider Login URL” field

  • Identity Provider Logout URL: Input the Identity Provider Logout URL (Optional field).
    It is the domain to which Sprinklr redirects after logout

  • SAML User ID Type: Choose the desired SAML User ID Type 

    • If the customer is authenticating on email, leave at the default Assertion contains User's sprinklr.com username selection

    • If they are authenticating on an ID value and not email, select Assertion contains the Federation ID from the User object instead


The assertion sent by the IDP either contains the user's sprinklr.com username or federation ID from the user object for authentication. While using federation ID for authentication clients add the fed ID in Sprinklr as well. Steps to add federation ID in user profile is in
this link.

  • SAML User ID Location: Choose the desired SAML User ID Location

    • If the customer is sending the authentication value (email or ID) in the NameID, leave at the default User ID is in the Name Identifier element of the Subject statement selection. 

    • If the customer is sending authentication value in another attribute, select User ID is in an Attribute element & enter the name of the attribute in the given space

  • Request Binding: Select HTTP POST or HTTP Redirect

  • For SSO Checklist it corresponds to “AuthNRequest: POST or REDIRECT bindings?” field

For HTTP POST, IDP should have a certificate that we have given as we will look for it. When the response comes we will get that info in the response. (Not needed for HTTP REDIRECT)

  • User Not Provisioned Error Message: Enter the message as per your requirement (Optional)

  • Do you want to enable SSO for advocacy?: If yes, check the box and select the Name from the drop-down menu & enter the desired Attribute.

  • Use new SSO Certificate: Check box for Use New SSO Certificate. 

  • Request Signature Method: Select the Request Signature Method from the drop-down menu. 

    • Metadata:<ds:DigestMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#sha256“/>

    • For SSO Checklist it corresponds to the “SHA1 or SHA256?” field

  • Identity Provider Certificate: Fill out the Identity Provider Certificate in PEM Format

    • For Metadata file it corresponds to the “<ds:X509Certificate>” field

    • For SSO Checklist: Public Key Certificate of the Identity Provider of the Client field

You can use this link to format the certificate in the required format.
Remember: Your certificate should start with -----BEGIN CERTIFICATE-----
                    Your certificate should end with -----END CERTIFICATE-----


In case the IDP certificate expires, the SSO setting needs to be updated with the new certificate by Success manager/Client:

Remember to keep a backup of the existing certificate in a notepad.


Steps to Update SSO Certificates from UI

  • Go to the location below in the UI to update the SSO Certificate.
    Settings >> Manage Customer >> Single Sign-Ons >> Principal SSO >> Edit


  • Check if the certificate is updated under "Identity Provider Certificate"

  • Get the new certificate from the user and replace the existing Certificate here

  • The certificate should start with "-----BEGIN CERTIFICATE-----" and
    end with "-----END CERTIFICATE-----"

  • The format of the Certificate needs to be in PEM. You can use this link to format the certificate in the required format.

SSO Emulation

You can simulate all steps of the SSO flow before saving the configuration to ensure that you can save the SSO configuration only after successfully emulating all steps and resolving all the errors that are displayed after emulation.

In the Auto Provisioning section, click Start Test to simulate all steps of the SSO flow before saving the configuration.