Multi-tenancy with Orgs

Table of Contents

Orgs in ThoughtSpot
Feature availability on a multi-tenant instance
Authentication considerations for embedded apps
Get started with Orgs

If your deployment requires logical separation of departments within your organization, or if it involves supporting many distinct organizations from a single application instance, use the Orgs feature. Using Orgs, you can set boundaries within the ThoughtSpot system and isolate each tenant’s data in such a way that it is independent of and invisible to other tenant workspaces configured on the same application instance.

The following figure illustrates the primary difference between a single-tenant and multi-tenant deployment:

Important

The Orgs multi-tenancy features require the ThoughtSpot Analytics Enterprise Edition or ThoughtSpot Embedded license.
The Orgs feature is disabled by default on ThoughtSpot clusters. To enable this feature on your instance, contact ThoughtSpot Support.
Once you enable the Orgs feature on your instance, there will be one non-deletable Org referred to as the Primary Org in your instance.
After you enable the Orgs feature on a cluster, you can’t turn off the ability to create Orgs.

Orgs in ThoughtSpot🔗

If the Orgs feature is enabled on your instance, a Primary Org will be created by default. This default Org is identified as Org 0. The cluster administrator can create an Org for each tenant account, configure groups and assign users, and define access to data objects within that org. Each Org serves as an independent container with its own set of users, groups, and data objects, and provides the same user experience as that of a regular ThoughtSpot instance.

The following diagram depicts the Orgs presentation on a multi-tenant ThoughtSpot instance.

User roles🔗

On a multi-tenant instance, ThoughtSpot supports the following user roles:

Cluster administrator
By default, the administrator of the primary Org (Org 0) is assigned the privileges of a cluster administrator. The cluster administrator can access all Orgs and perform the following CRUD operations:
- Create and manage Orgs
- Add users to Orgs
- Administer cluster
- Manage user identity and access management (IAM)
  
  The cluster administrator can also act as an individual Org administrator and perform administration tasks within an Org context.
Org administrator
An Org administrator administers and manages users, groups, and data objects of their respective Org. Typically, Org administrators create groups within their Org and assign privileges to the users of their Org.
Org users
An Org user can access only the Orgs to which they belong. A user can belong to more than one Org and access data objects and metadata based on the privileges assigned to the groups to which they belong.

All Orgs scope🔗

On a multi-tenant ThoughtSpot instance, all operations are run in the context of the Org.

If a cluster administrator wants to perform a Create, Read, Update, or Delete (CRUD) operation or apply a configuration change to all Orgs, they must override the Org context and apply the changes at the All Orgs level via the UI or API calls. If using API, the cluster administrator must explicitly set the Org scope to ALL in their API requests.

Note

The Primary Org (Org 0) is the default Org and cannot be deleted.
Each Org is identified by a unique name and ID, and can have its own users and groups.
Groups are unique to an Org and can be created only within the context of an Org.
A user can belong to multiple Orgs and can switch between the Org context. At any given time, a user can only access objects and data in the Org they have logged into.
A user from one Org cannot share an object with the users of another Org.

Feature availability on a multi-tenant instance🔗

On an Orgs-enabled cluster, certain UI and API operations are allowed only at the cluster level. The following table lists the features and configuration operations allowed at the cluster or individual Org level.

Feature category At the cluster level (All Orgs) At the Org level

Feature category	At the cluster level (All Orgs)	At the Org level
User management	✓ User creation and management ✓ User association to Orgs	✓ User creation and management ✓ User association to groups
Groups and privileges	–	Groups and privilege configuration and management are restricted to Org context only.
Authentication	✓ Local authentication configuration ✓ Trusted authentication ✓ SAML authentication configuration OIDC authentication configuration is not supported	✓ Trusted authentication
Access to `Develop` tab	✓	✓ Access to the Develop* tab at the Org level is disabled by default. To enable Develop tab and its features at the Org level, contact ThoughtSpot Support.*
Security settings (CORS settings)	✓	✓
Security settings (CSP settings)	✓	–
Data connections and objects	–	✓ Object creation and management ✓ Data connection creation and management Cluster administrators can create and edit connections in any Org. Org administrators can create and edit their connections in their respective Orgs. Starting from 9.0.0.cl, cluster administrators can share connections with Org administrators and also with users who have data management privileges. Org administrators cannot view or edit the connections created by the Cluster administrators if the connection object is not shared with them.
Access control	✓ Org creation for data isolation ✓ User mapping to Orgs	✓ Groups and privilege assignment to users ✓ Object sharing with other users and groups in the Org
Customization	✓ Custom domain configuration ✓ From ID customization for system notifications ✓ Onboarding settings and welcome message customization	–
Style customization and CSS overrides	✓	✓ Style customization settings can be applied only on the Develop > Customizations > Style customizations page. Per-Org CSS overrides can be applied using the Visual Embed SDK. To enable this feature on your instance, contact ThoughtSpot Support.
Custom actions	–	✓ Custom action creation and group association are supported by default at the Primary Org (Org 0) level. To enable action customization at the Org level, contact ThoughtSpot Support
Link customization for embedded instances	–	✓ The Link customization feature is supported by default at the Primary Org (Org 0) level. To enable link customization at the Org level, contact ThoughtSpot Support.
Developer Playground	–	✓ The Visual Embed and REST API Playgrounds are available by default at the Primary Org (Org 0) level. To enable Playground access at the Org level, contact ThoughtSpot Support.
REST API v1 operations	✓ Org endpoints for CRUD operations Group provisioning and custom action group association API operations are not supported.	All API operations are supported except for the CRUD operations of Orgs.
REST API v2 ^Beta endpoints (Deprecated from 9.0.0.cl onwards)	–	–
REST API v2.0 endpoints	–	✓ For production use cases, ThoughtSpot recommends using REST API v1 endpoints.

User management

✓ User creation and management

✓ User association to Orgs

✓ User creation and management

✓ User association to groups

Groups and privileges

–

Groups and privilege configuration and management are restricted to Org context only.

Authentication

✓ Local authentication configuration

✓ Trusted authentication

✓ SAML authentication configuration

OIDC authentication configuration is not supported

✓ Trusted authentication

Access to Develop tab

✓

Access to the Develop tab at the Org level is disabled by default. To enable Develop tab and its features at the Org level, contact ThoughtSpot Support.

Security settings (CORS settings)

✓

Security settings (CSP settings)

✓

–

Data connections and objects

–

✓ Object creation and management

✓ Data connection creation and management

Cluster administrators can create and edit connections in any Org.
Org administrators can create and edit their connections in their respective Orgs.
Starting from 9.0.0.cl, cluster administrators can share connections with Org administrators and also with users who have data management privileges. Org administrators cannot view or edit the connections created by the Cluster administrators if the connection object is not shared with them.

Access control

✓ Org creation for data isolation

✓ User mapping to Orgs

✓ Groups and privilege assignment to users

✓ Object sharing with other users and groups in the Org

Customization

✓ Custom domain configuration

✓ From ID customization for system notifications

✓ Onboarding settings and welcome message customization

–

Style customization and CSS overrides

✓

Style customization settings can be applied only on the Develop > Customizations > Style customizations page. Per-Org CSS overrides can be applied using the Visual Embed SDK. To enable this feature on your instance, contact ThoughtSpot Support.

Custom actions

–

✓

Custom action creation and group association are supported by default at the Primary Org (Org 0) level. To enable action customization at the Org level, contact ThoughtSpot Support

Link customization for embedded instances

–

✓
The Link customization feature is supported by default at the Primary Org (Org 0) level. To enable link customization at the Org level, contact ThoughtSpot Support.

Developer Playground

–

✓
The Visual Embed and REST API Playgrounds are available by default at the Primary Org (Org 0) level. To enable Playground access at the Org level, contact ThoughtSpot Support.

REST API v1 operations

✓ Org endpoints for CRUD operations

Group provisioning and custom action group association API operations are not supported.

All API operations are supported except for the CRUD operations of Orgs.

REST API v2 ^Beta endpoints
(Deprecated from 9.0.0.cl onwards)

–

REST API v2.0 endpoints

–

✓
For production use cases, ThoughtSpot recommends using REST API v1 endpoints.

Authentication considerations for embedded apps🔗

On a multi-tenant cluster with Orgs, ThoughtSpot supports local, SAML, and trusted authentication methods. If you are using Visual Embed SDK to embed ThoughtSpot in your app, use AuthType.Basic for local authentication, AuthType.TrustedAuthToken for trusted authentication, and AuthType.EmbeddedSSO or AuthType.SAMLRedirect for SAML SSO authentication. For more information, see Authentication.

Trusted authentication🔗

If Trusted authentication is enabled, Org users can obtain authentication tokens using the secret key. Org administrator or an authorized third-party authenticator service can also generate tokens on behalf of a ThoughtSpot user by using the secret key.

Starting from 9.2.0.cl, ThoughtSpot supports generating separate secret keys for each Org. To enable this feature on your instance, contact ThoughtSpot Support. When this feature is enabled, Org users can obtain separate authentication tokens to access their Org and switch between Orgs seamlessly.

Just-in-time user creation and dynamic privilege assignment🔗

If trusted authentication is configured in the SDK, you can request an authentication token via API calls to any of the following REST API endpoints:

REST API v1 - /tspublic/v1/session/auth/token
REST API v2 - /api/rest/2.0/auth/token/full

If the user doesn’t exist in the ThoughtSpot system, you can autocreate a user account just-in-time and dynamically assign privileges by adding the user to groups.

The /tspublic/v1/session/auth/token API endpoint also allows you to define the Org context to which the user must be logged in to after successful authentication. However, the API requests to REST API v2.0 endpoint will automatically generate the token based on your current session context.

For more information, see Obtain an authentication token and Trusted authentication.

SAML authentication🔗

For SAML authentication, ensure that the Org support is enabled for SAML authentication. For more information, see ThoughtSpot Product Documentation. You must also configure the Org information on your IdP so that the SAML users are allowed to access the Orgs to which they belong. To enable Orgs support for SAML authentication on ThoughtSpot, contact ThoughtSpot Support.

The following conditions apply to SAML authentication on a multi-tenant setup:

If Orgs support is enabled for SAML authentication, and the Org objects to which the user belongs are configured on ThoughtSpot:
- Multiple Org names can be sent in the SAML assertion.
- If the Org names are not sent in the SAML assertion, the user is logged in to the default Org (Primary Org).
- If the user already exists in ThoughtSpot, the user is allowed to access the Orgs sent in the SAML assertion.
- If the user does not exist in ThoughtSpot, the user is assigned to the Orgs sent in the SAML assertion but is not assigned to any group.
- If the user is already created in ThoughtSpot and assigned to Orgs and the SAML assertion has different Org names, the user is assigned to only the Orgs sent in the SAML assertion. For example, if a user belongs to Org A and Org B and the SAML assertion includes Org C and Org D, the user is assigned to Org C and Org D and removed from Org A and Org B.
If Orgs support is enabled for SAML authentication and the Org objects are not configured ThoughtSpot, the authentication process returns an error.
If the Orgs support is not enabled for SAML authentication and Org objects are not configured, the user is assigned to the default Org (Primary Org).

Get started with Orgs🔗

Note	Before you get started with Orgs, make sure you read the documentation and understand the features supported on a multi-tenant setup.

To get started with Orgs:

Configure your ThoughtSpot instance as a multi-tenant cluster. To enable multi-tenant setup on your instance, contact ThoughtSpot support.
Log in to your application instance as an administrator.

If the Orgs feature is enabled on your cluster, a Primary Org is created by default, and you will be logged in to the Primary Org context.
Create Orgs in the Admin page of the UI or via REST API.

To create and manage Orgs, you must set the Org context to All. To do this, you can switch to the All Orgs tab in the Admin page of UI or pass the Org scope ALL in your API requests to Orgs API endpoints. For more information, see Org API.
Create users and map the users to Orgs.

You can create an administrator profile for each Org and let these Org administrators manage users, groups, and role privileges in their respective Orgs.

Note that ThoughtSpot allows provisioning groups only within the context of an Org. You must ensure that ThoughtSpot users are mapped to appropriate Orgs and the groups within these Orgs for user access control and data security.