Just-in-time provisioning
ThoughtSpot can use the SSO process to create users and assign them to ThoughtSpot groups.
The capabilities are the same between SAML, OIDC, and trusted authentication methods, but the implementations of each are slightly different.
User creation🔗
Just-in-time provisioning (JIT) creates a user if they do not already exist at the time of SSO sign-in.
Creating a user via JIT requires the assertion containing username, email address, display name, and org (if Orgs are enabled).
Only the ThoughtSpot username is required for SSO when not using JIT.
Users created via JIT are identical to users created manually or via the REST APIs, except they do not have passwords in Thoughtspot; they cannot access ThoughtSpot other than through the SSO method. You can assign a password to any user later using the UI or a REST API call.
Group assignment🔗
Users can be assigned to ThoughtSpot groups via JIT as well. The list of groups should be composed of group_name properties, rather than display_name.
JIT group assignment is a full replacement of the user’s set of groups.
Groups that do not exist will be created, but a ThoughtSpot group by default provides no access control or privileges.
Groups created via JIT will have the same group_name and display_name. This name will be what is used by the ts_groups property in any RLS rules.
If you need more control over group creation and assignment, see the REST API creation and update methods below.
Trusted authentication🔗
Both V1 and V2 tokens support just-in-time provisioning of users.
REST API v2 request🔗
The auto_create: true parameter of the /auth/token/full endpoint enables the token for just-in-time provisioning. The display_name and email parameters are also required for JIT user creation. If Orgs are enabled, you must specify org_id parameter as well to direct ThoughtSpot to know which Org to create the user in.
The group_identifiers parameter should only be specified if you want to enable JIT group assignment. Passing group_identifiers: [] will set the user to be assigned to no groups, while excluding the group_identifiers parameter altogether will leave the user assigned to their existing set of groups.
REST API v1 request🔗
Starting from 8.9.0.cl, the /tspublic/v1/session/auth/token endpoint can provision a new user by setting the autocreate property to true.
SAML🔗
SAML SSO can be configured with the option Automatically add SAML users to ThoughtSpot upon first authentication. Please see the SAML SSO configuration documentation for the full instructions.
Note under the Configure the IdP server for SAML authentication section of the documentation on how to properly map the username, displayName, email, and orgId properties from the IdP.
JIT group assignment can be enabled for SAML SSO via a support ticket.
OIDC🔗
OIDC SSO can be configured for JIT user creation, as the necessary properties should already be configured as part of the claims.
JIT group assignment can be enabled for OIDC via a support ticket.
Determine Org IDs🔗
Org IDs are integers that are created automatically when a cluster administrator creates an Org.
If Orgs is enabled, you do need to specify the Org ID when creating a user.
An account with cluster administrator privileges can use the /tspublic/v1/org/search or /api/rest/2.0/orgs/search endpoints to get a list of all Orgs available on your cluster.
To know the Org ID of the current Org, you can send a GET request to the /tspublic/v1/session/orgs API endpoint within the browser.
REST API creation and update methods🔗
Since JIT group provisioning does not provide the full configuration of groups or assign access control, you can use the REST APIs to create, edit, and synchronize groups with the embedding application.
The user and group privileges REST API documentation covers the additional requests related to authorization.
User creation can be accomplished using the get user details and create user REST APIs.
REST APIs other than token requests must be performed using a ThoughtSpot user account with the appropriate level of administrative privileges, versus simply using the secret_key.
For example, you could use the REST API v1 or REST API v2.0 group endpoints to implement ThoughtSpot groups that are intended for use in Row Level Security (RLS) rules. For these groups, the group name must match exactly with a value in a column in the data warehouse, so the name of the group itself serves as a data entitlement. You could adjust the flow described in the preceding section to create any group for RLS that did not already exist and assign it to the user, which would bring the process closer to a Role-based access control (RBAC) or Attribute-based access control (ABAC) pattern.