Multi-tenancy with groups

Each group and user has a "sharing visibility" property, which can be set to SHAREABLE or NOT SHAREABLE.

When a group is NOT SHAREABLE, the users within that group cannot share to that group or to other users in that group.

NOT SHAREABLE groups provide access to content (or privileges) without breaking user separation. Each user has no concept they belong to the group; they simply have access to the content.

When a user is set to SHAREABLE, other users within the same SHAREABLE group as that user can share content to them individually.

The non-admin users can only share to:

SHAREABLE users' names are never seen by other users unless both users belong to the same SHAREABLE group.

To allow for multi-tenanted self-service, SHAREABLE groups can be created for each organization, so that only the users of each organization can share with one another. The choice of whether to make users shareable is up to you; if you prefer all sharing to be done at the group level, you can set all users to NOT SHAREABLE.

We will call a database multi-tenanted when a single set of credentials can see all of the data for all customer organizations. In a multi-tenanted database, there is typically a column named “customer_id” or “tenant_id” on every row of data within the database; we’ll call it the tenant key. Filtering against this tenant key splits the data for each customer organization.

If the rules of multi-tenancy are more complex than a simple tenant key on each row of data, there should at least be one table which defines the tenants and can be joined in a way to filter the other tables appropriately.

If the cloud data warehouse you are connecting to is multi-tenanted as described above, then you will only need one set of data objects in ThoughtSpot. The tables will be configured with row-level security (RLS), so that every query will filter against the tenant key in the database.

If there is a separate database connection for each customer organization, then the database pattern is single-tenant, and you will need to create objects for each tenant. ThoughtSpot represents all data and content objects using the ThoughtSpot Modeling Language, with REST APIs for automating the creation or deployment of each tenant’s data and content objects via TML.

There are two basic architectures for storing different tenants' data within cloud data warehouses. The following sections describe a best practice starting point for deploying in ThoughtSpot depending on which of the architectures you have chosen for your CDW. REST APIs are available to deploy these patterns at scale. You can create groups, create users, add users to groups, publish content from TML objects, and share that content with the appropriate groups.

Most software development processes involve creating content in a restricted “development” environment, and then once the changes are finished, placing it in a “test” environment. Within a single ThoughtSpot instance, development and test content can be considered as another tenant’s, with access restricted to only app developer users.

For both of the multi-tenancy patterns above, add additional groups for dev and test with only members of your app development team.

Privileges in ThoughtSpot control the set of product features a user has access to. Privileges are assigned to users through groups.

A user’s privilege set is additive based on the groups they belong to; the user at all times has the full set of any privilege from any group they belong to. This is also to say that privileges do not apply only to content shared to the group.

The simplest best practice for assigning privileges to users is to create privilege groups, set to not shareable, with no content shared to them. When configured this way, a privilege group acts like a role definition, and users from any tenant can all belong to one of the server-wide privilege groups.

The REST API returns a user’s privilege set as part of the response from the GET /user/ endpoint.

ThoughtSpot groups can be hierarchical; one group can be the parent of another group and so forth. We recommend not to use hierarchical groups in a multi-tenanted situation.

When groups are hierarchical, the rules for how privileges and row-level security are derived become complex. In particular, row-level security is achieved by returning the string value of the names of all groups a user belongs to. Hierarchical groups can vastly inflate the number of group names returned in an RLS query, reducing performance and introducing complexity in auditing.

As mentioned above, you will want to use REST API automation to synchronize the group structures and audit that you have configured them correctly. Another tool for auditing is to create test user accounts — user accounts that belong to the app developer, but are configured as if they are part of a customer organization.

Depending on your internal security policies, you may only want your test user accounts to log in to content attached to test data, rather than production customer data. In this case, you will create a full suite of test content groups simulating at least two “customers”, and test user accounts for each “access level” that exists for the end customer users.

Tags are available in ThoughtSpot to label content and assist in searching. Content can be tagged with multiple tags.

Tags can be used as part of searches using the Metadata REST APIs, with the caveat that it is an inclusive list; the response will include all content with any of the tags sent, as opposed to only including content with the full set of tags.