SAML SSO authentication

SAML SSO authentication

ThoughtSpot supports the Single Sign-On (SSO) authentication method with the Security Assertion Markup Language (SAML) authentication and authorization framework. With SAML SSO, users can authenticate to the SAML identity provider to access the ThoughtSpot application or the embedded ThoughtSpot content in an external web application. It also allows them to navigate seamlessly between different applications with their existing credentials.

About SAML authentication🔗

SAML is an XML standard that allows secure exchange of user authentication and authorization data between trusted partners. It enables the following entities to exchange identity, authentication, and authorization information:

SAML entities🔗

The SAML SSO authentication involves several entities.

  • Identity Provider (IdP)

    The Identity Management system that maintains the user identity information. The IdP acts as a SAML authority and authenticates SSO users. ThoughtSpot supports the SAML authentication framework with popular Identity Providers such as Okta, Azure Active Directory, PingFederate, Microsoft Active Directory Federation Services (ADFS), and Onelogin.

  • Service Provider (SP)

    The provider of a business function or application service; for example, ThoughtSpot. The SP relies on the IdP to authenticate users before allowing access to its services.

  • Federated user

    A user whose identity information is managed by the IdP. The federated users have SSO credentials and authenticate to the IdP to access various application services.

SAML assertion and attributes🔗

Both SP-initiated and IdP-initiated authentication workflows rely on assertions that are exchanged between the SAML endpoints through a web browser.

Some of the most commonly used elements are:

  • SAML assertion

    The user authentication and authorization information issued by the IdP. SAML assertions contain all the information necessary for a service provider to confirm if the user identity is valid.

  • Metadata

    Data in the XML format to establish interoperability between the IdP and SP. It contains the URLs of the endpoints, entity ID, and so on.

  • Assertion Services Consumer (ACS) URL

    The endpoint URL to which the user’s browser sends the SAML response received from the IdP after authenticating a user.

  • Entity ID

    A unique service name to identify the client application from which the SSO login request originates.

  • SAML attributes

    The attributes associated with the user; for example, username and email address.

SSO workflows🔗

Most SAML deployments support the following authentication workflows:

  • SP-initiated SSO

    In the SP-initiated SSO authentication flow, the SSO request originates from the client application. For example, when a user tries to access the ThoughtSpot standalone application or the ThoughtSpot content embedded in an external application, a federation authentication request is created and sent to the IdP server.

  • IdP-initiated SSO

    In the IdP-initiated SSO authentication flow, the user authenticates to the IdP first. The browser then redirects the login request to the host application and allows the user to access the requested content.

SAML authentication workflow on an embedded instance🔗

With SAML SSO authentication, your host applications can allow federated users to access the embedded ThoughtSpot content without the need for a separate ThoughtSpot login.

A typical SP-initiated SSO authentication workflow consists of the following steps:

  1. A federated user tries to access a ThoughtSpot page, Liveboard, or visualization in the host application.

  2. The host application sends the authentication request to ThoughtSpot.

  3. If the SAML SSO authentication method is configured for the ThoughtSpot embedded instance, the browser sends the SAML request to the IdP.

    • If the user has already authenticated to the IdP, the login request is redirected to the host application.

    • If the user is not authenticated, the browser displays a login page to allow the user to authenticate to the IdP and then redirects.

  4. The requested ThoughtSpot page or resource is displayed.

The following figure illustrates the SAML SSO authentication workflow for embedded ThoughtSpot content users:

SAML authentication

Visual Embed SDK flow🔗

When using the Visual Embed SDK, the embedding application page is redirected to the IdP when the init() function is called using AuthType.SAMLRedirect. This flow happens outside of embedded ThoughtSpot component and returns the browser eventually back to the page of the embedding app, where the Visual Embed SDK will load the ThoughtSpot content.

Enabling automatic SAML redirect🔗

If you are embedding without the Visual Embed SDK or using AuthType.None, the IdP flow will occur when the ThoughtSpot content is loaded. The general SAML configurations in ThoughtSpot will be obeyed in this scenario, and you will also need to configure the IdP to allow the flow to complete. To achieve a seamless sign-on without the Visual Embed SDK, contact ThoughtSpot Support to enable automatic SAML redirect on your instance. Note that this will apply to all users even when not embedding.

When automatic SAML redirect is enabled, you can override it when necessary by appending the following query parameter to a ThoughtSpot URL:

disableSAMLAutoRedirect=true
Note

Make a note of all of the redirects within the SAML workflow. Each server must be configured properly to allow the inbound and outbound portions of the SAML flow. If you encounter errors while configuring and testing, go to the Network tab of the browser’s developer tools to see which server within the workflow is generating the error.

Configuration steps🔗

To configure SAML SSO authentication on the ThoughtSpot embedded instance, complete the following steps:

Before you begin, make sure you have the admin user privileges to configure SAML support on ThoughtSpot.

Enable SAML authentication on ThoughtSpot🔗

You need admin privileges to enable SAML SSO authentication.

  1. Configure the ThoughtSpot application instance on your IdP server.

  2. Log in to your ThoughtSpot application instance.

  3. From the top navigation bar, click the Admin tab.

  4. Click SAML.

  5. Click Configure.

  6. Configure the following attributes:

    ThoughtSpot Service Address

    A fully qualified and resolvable domain name for the ThoughtSpot service. For example, thoughtspot.thoughtspot-customer.com.

    Port

    Port of the server where your ThoughtSpot instance is running. For example, port 443.

    Unique Service Name

    The unique key used by your Identity Provider to identify the client. For example, urn:thoughtspot:callosum:saml, or https://ssoappname.microsoft.com/ab12c3de4.

    This is also called the SP Entity ID.

    Skew Time in Seconds

    The allowed skew time, after which the authentication response is rejected and sent back from the IdP. The commonly used value is 86400. The default value is 3600.

    Protocol

    The connection protocol for ThoughtSpot. For example, https.

    IDP Metadata XML File

    The IdP metadata file. For example, idp-meta.xml. Upload the Identity Provider’s metadata file provided by your IdP. You need this file so that the configuration persists over upgrades. The best practice is to set it up on persistent or HA storage (NAS volumes), or in the same absolute path on all nodes in the cluster. If your IdP needs an ACS URL to create the metadata file, use https://<hostname_or_IP>/callosum/v1/saml/SSO.

    Automatically add SAML users to ThoughtSpot upon first authentication

    Specify if you want to add SAML users to ThoughtSpot when they first authenticate. If you select yes, the new users will be added to ThoughtSpot upon their first successful SSO login. If you select no, the SAML users will not be added in ThoughtSpot upon their first successful SSO login. Instead, you must add users manually.

    ThoughtSpot can also add users to groups sent within the SAML assertion. To enable and configure the SAML groups capabilities, contact your ThoughtSpot team.

    For additional authorization settings beyond user creation and group assignment, see Authentication and security.

  7. Click Save.

Configure the IdP server for SAML authentication🔗

To enable IdP to recognize your host application and ThoughtSpot as a valid service provider, you must configure the IdP with the required attributes and metadata.

ThoughtSpot supports SAML authentication with several identity and access management providers, such as Okta, OneLogin, PingFederate, Microsoft ADFS, Microsoft Azure Active Directory, and so on. If you want to use one of these providers as your IdP, make sure you follow the SAML configuration steps described in the Identity provider’s documentation.

To determine if ThoughtSpot supports your preferred IdP, contact ThoughtSpot support.

Note

When configuring SAML 2.0, make sure you map the SAML user attributes to appropriate fields. For example, you must map the SAML user’s username to the NameId attribute in OneLogin. Similarly, in Okta, you must map the username to userPrincipalName. You must also ensure that the email address of the user is mapped to the mail attribute and the display name subject value to displayName. If your IdP does not allow you to import the IdP metadata XML file, you must map these values manually.

Configure IdP to allow iframe embedding🔗

Embedding ThoughtSpot components can involve an iframe in the display process. By default, most IdPs do not allow a SAML workflow from an iframe embed. To enable a fully seamless SSO experience for your end users, you will need to have your IdP configured to allow an iframe to complete the SAML workflow.

An example of this setting is the Enable iframe embedding in Okta’s advanced configuration section. Each IdP will have its specific way to enable an iframe-initiated workflow.

Enable SSO authentication in the Visual Embed SDK🔗

If you want to use SSO authentication for embedded ThoughtSpot content, make sure you set the AuthType parameter to SAML in the SDK when calling the init function from your application.

init({
    thoughtSpotHost: "https://<hostname>:<port>",
    authType: AuthType.SAMLRedirect,
});

Allow SAML Redirect Domains🔗

If you have to redirect SAML users to a URL hosted on a different domain, make sure you add this URL to the list of allowed domains in ThoughtSpot.

To add a SAML redirect domain, follow these steps:

  1. Log in to your ThoughtSpot application instance as an admin user.

  2. Click the Develop tab.

  3. Under Customizations, click Security settings.

  4. Click Edit.

  5. In the SAML redirect domains text box, add the domain names. Valid values are:

    • Domain name strings without port and protocol. For example, thoughtspot.com,www.thoughtspot.com

    • Comma-separated values. For example, thoughtspot.com,thoughtspot.cloud

    • IPv4 addresses. For example, 255.255.255.255

    Note

    Do NOT include the protocol in the SAML redirect domain name string to avoid configuration errors.

  6. Click Save changes.