Multi-tenancy with Orgs

Multi-tenancy 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:

Multi-tenant ThoughtSpot environment
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 as Org 0.

The Primary Org behaves as the administration Org for all other Orgs in the cluster.

Each Org other than the Primary 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.

If a user only belongs to a single Org, their experience of ThoughtSpot is as if it were single-tenant.

If a user belongs to multiple Orgs, they will see a menu allowing them to switch between the Orgs they belong to.

All activity within ThoughtSpot is always within the context of one Org, even if the user has access to multiple Orgs. They can switch between Orgs but not do any actions across Orgs.

Administering Orgs🔗

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.

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

Multi-tenant ThoughtSpot environment

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

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

Note

To enable Orgs support for SAML authentication on ThoughtSpot, contact ThoughtSpot Support.

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.

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

OIDC authentication🔗

Note

To enable Orgs support for OIDC authentication on ThoughtSpot, contact ThoughtSpot Support.

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

  • If Orgs mapping is enabled for OIDC authentication, and the Org objects to which the user belongs are configured on ThoughtSpot:

    • Multiple Org names can be sent in the OIDC assertion.

    • If the Org names are not sent in the OIDC assertion, the login fails.

    • If the user does not exist in ThoughtSpot, the user is assigned to the Orgs sent in the OIDC assertion if Auto create user (JIT) is enabled.

    • If the user is already created in ThoughtSpot and assigned to Orgs and the OIDC assertion has different Org names, the user is assigned to only the Orgs sent in the OIDC assertion. For example, if a user belongs to Org A and Org B and the OIDC 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 the Org objects are not configured on ThoughtSpot, the Orgs mapping with OIDC authentication process returns an error.

  • If the Orgs mapping with OIDC authentication is not enabled on ThoughtSpot, and Org objects are not configured, the user is assigned to the default Org (Primary Org).

  • If the Org mapping is enabled on the ThoughtSpot cluster, the Group mapping will not work.

For more information on OIDC authentication, see OpenID Connect authentication.