SAML 2.0 SSO

Updated 

11 days ago

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

​

Steps to Configure SAML 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. Ensure SSO configurations are enabled on Sprinklr before proceeding with below steps, raise a support ticket for the same if they are not enabled. 

2. Log in to Sprinklr as a Global Admin, and navigate to All Settings > Login & Security Settings > Single Sign-Ons > Add Single Sign On.

​

​

​

3. Click SAML under Select the Type of Single Sign On. 

​

​

4. Fill in details in the mandatory fields, and click Save in the bottom right corner to save your SSO configuration.

Field Descriptions for SAML 2.0 SSO Setup in the Create Single Sign On

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 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.

​

​

​

Was this article helpful?

Related Articles

Loading...