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, For detailed information on SAML identities, see the following page SAML entities.

Both SP-initiated and IdP-initiated authentication workflows rely on assertions that are exchanged between the SAML endpoints through a web browser. For detailed information on these, see the following page SAML assertion and attributes.

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 with IAMv1🔗

Note

You need admin privileges to enable SAML authentication on ThoughtSpot.

The following attributes need to be configured on your ThoughtSpot instance:

ThoughtSpot Service Address

A fully qualified and resolvable domain name for the ThoughtSpot service. This must be in the format <cluster-name>.thoughtspot.cloud.

Port

Enter 443 in this box. This is the port of the server where your ThoughtSpot instance is running.

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.

Skew Time in Seconds

The allowed skew time, after which the authentication response is rejected and sent back from the IDP. 86400 is a popular choice. The default is 3600.

Protocol

The connection protocol for ThoughtSpot. Use https.

IDP Metadata XML File

The absolute path to your Identity Provider’s metadata file. This file is provided by your IDP. For example, idp-meta.xml.

For detailed information on enabling SAML authentication on your ThoughtSpot instance with IAMv1, see this page Enable SAML authentication

Enable SAML authentication on ThoughtSpot with IAMv2🔗

Note

You need admin privileges to enable SAML authentication with IAMv2 on ThoughtSpot.

With IAMv2, ThoughtSpot powers its internal authentication with Okta. IAMv2 involves several external improvements to authentication, including security enhancements.

To enable SAML authentication using IAMv2, the SAML2 IDP tile needs to be selected from the IdP options in the Admin panel. The following IdP details are to be provided:

Connection name

Provide a name for the configuration of the connection to your identity provider, helping to distinguish and manage multiple connections. This appears as the connection name on the Admin Console.

IDP provider certificate

Your IdP public key certificate to verify SAML messages and assertion signature (usually provided by the team responsible for the IdP in your organisation).

IDP issuer ID

IDP issuer URI.

IDP single sign on URL

Your IDP endpoint. Receives the authentication request from ThoughtSpot.

Advanced configuration

Optional

Request binding

Binding used for mapping the SAML protocol message. The default is HTTP-POST.

Request signature algorithm

Signature algorithm used to sign the authentication request to your IDP. The default is SHA-256.

Response signature algorithm

The minimum signature algorithm used to validate the SAML assertion from the IDP. The default is SHA-256.

Max clock skew time in seconds

The allowed skew time, after which the authentication response is rejected and sent back from the IDP. The default is 86400.

The IdP details will have to be mapped with these ThoughtSpot attributes:

Username

ThoughtSpot username corresponding to the username from the IdP.

Email

ThoughtSpot email associated with the email of the user in the IdP.

Display name

Optional. The display name for the user.

roles

Optional. Roles associated with the user. This mapping is crucial for assigning the correct roles and permissions to users based on their authentication through SAML.

For detailed information on enabling SAML authentication on ThoughtSpot using IAMv2, and attributes, see this page Enable SAML authentication.

You can map your SAML groups,or groups and Orgs from your IdP to your ThoughtSpot. This means that you do not have to manually recreate your groups and Orgs in ThoughtSpot if they are already present in your IdP. Refer to Configure SAML group mapping.

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.