How do I restrict embedded data by user attributes?
有效阅读仅保存在当前浏览器,用于「为你」推荐;暂停或清除记录。
DataHot 速览
In ThoughtSpot, use attribute-based access control (ABAC) through row-level security (RLS) variables. Create a formula variable for each attribute, reference it with ts_var() in an RLS rule on each Table that holds restricted data, and pass each user's values in a custom authentication token from yo
本文目录 8 节
原文
In ThoughtSpot, use attribute-based access control (ABAC) through row-level security (RLS) variables. Create a formula variable for each attribute, reference it with ts_var() in an RLS rule on each Table that holds restricted data, and pass each user's values in a custom authentication token from your backend. One dashboard then shows each user only the rows their attributes allow. Older setups passed filter_rules and parameters in the token (ABAC via JWT). That method is deprecated as of 26.3.0.cl: existing setups keep working, and new builds should use variables (ABAC via JWT, deprecated, migration guide).
Checked against the ThoughtSpot Cloud 26.10.0.cl documentation, October 2026.
Attribute-based access control (ABAC) grants data access from user attributes, such as region or product line, instead of from group membership. ThoughtSpot implements ABAC with RLS variables: each attribute is a formula variable that RLS rules read with ts_var(), and your backend sets each user's values in their authentication token.
This approach is particularly useful for multi tenant analytics environments, where different customers or users need access to specific datasets within the same embedded analytics application.
What should you check when you compare tools?
Entitlements change: users move regions, customers buy new product lines. With attributes in the sign-in token, access changes when your backend sends new values, with no new dashboards or groups. In ThoughtSpot the rule runs on the server, and Spotter, ThoughtSpot's AI analyst, "only sees what each user is permitted to see" (Spotter data handling).
For SaaS embedded analytics, attribute-based access control also makes it easier to manage user-level permissions across customer-facing applications without creating separate dashboards for every customer.
Ask any vendor:
- Can I pass user attributes at sign-in, instead of creating a group for every combination?
- When a user has no value, do they see all data or none?
- Can restricted values leak through search suggestions or AI answers?
How do I set it up?
1. Create a formula variable for each attribute with the REST API. You need the Can administer ThoughtSpot privilege, or Can manage variables when role-based access control (RBAC) is on:
POST /api/rest/2.0/template/variables/create
{ "type": "FORMULA_VARIABLE", "name": "region_var", "is_sensitive": false, "data_type": "VARCHAR" }The API doesn't need a default value. The Admin page's Variables tab currently does: choose one that returns no rows for your rule, such as TS_WILDCARD_NONE for an = rule.
2. Use it in an RLS rule on every Table that holds restricted data. Only = and != work with ts_var(). It needs ABAC via RLS, on by default from ThoughtSpot Cloud 26.4.0.cl.
region = ts_var(region_var)3. Create an app group and share the dashboard. Create one app group (app_users here), not shareable, and share the dashboard and its Model read-only with it (multi-tenancy within an Org).
When configuring an embedded analytics tool, this shared-dashboard approach allows multiple customers to use the same embedded dashboard while row-level security controls which records each user can access.
4. Pass the user's values in a custom authentication token, from your backend, when the user is new or the values change:
POST /api/rest/2.0/auth/token/custom
{
"username": "[email protected]",
"secret_key": "<SECRET_KEY>",
"persist_option": "REPLACE",
"auto_create": true,
"display_name": "Jane Doe",
"email": "[email protected]",
"groups": [{ "identifier": "app_users" }],
"validity_time_in_sec": 1800,
"variable_values": [{ "name": "region_var", "values": ["EMEA", "APAC"] }]
}Use REPLACE, which saves the values when the token is created. APPEND keeps old values, so a user who moves keeps their old access, and RESET and NONE don't work with variable_values. Values persist, so send variable_values only when the values change: every send rewrites them and adds load on the instance. This endpoint sets groups only when it creates the user, so add existing users to the app group yourself. Its Org field is org_identifier, not org_id; without it, the token goes to the user's last logged-in Org.
What else to know (ABAC via RLS):
- If a variable in an RLS rule has no value for a user, ThoughtSpot doesn't query the database: the user gets no data, and the error reads "No values are assigned to some or all Formula Variables".
- Wildcards depend on the operator. With region = ts_var(region_var), TS_WILDCARD_ALL returns every row and TS_WILDCARD_NONE returns none; with !=, the results flip. Test wildcards against each rule.
- Search suggestions aren't filtered by ts_var rules, because ThoughtSpot builds that index at admin level: "Disable indexing for columns and fields that must be restricted by ABAC."
Where can a variable's value be set?
A value can be set for an Org, for a user, or for a user on one Model, and the most specific wins: user and Model, then user, then Org. To set or change values outside sign-in, use the update-values API (26.4.0.cl+):
POST /api/rest/2.0/template/variables/region_var/update-values
{
"operation": "REPLACE",
"variable_assignment": [{
"assigned_values": ["EMEA"],
"org_identifier": "OrgA",
"principal_type": "USER",
"principal_identifier": "[email protected]",
"model_identifier": "SalesModel"
}]
}Leave out model_identifier to set the user's value for every Model, or also leave out principal_type and principal_identifier to set a default for the Org. An empty values array in a token doesn't clear a user's values. To clear them, send "operation": "REPLACE" with an empty assigned_values array to this endpoint.
How do I check it worked?
Sign in as a test user who isn't an admin and doesn't have the "Can administer and bypass RLS" privilege, and confirm they see only rows matching their values, with row-level security on for the Model. POST /api/rest/2.0/template/variables/search with "response_content": "METADATA_AND_VALUES" shows the values each user holds.
Still failing?
- "No values are assigned to some or all Formula Variables". A variable in an RLS rule has no value for that user. Set it in the token or with the update-values API.
- A user kept old access after moving. The token used APPEND. Use REPLACE.
- Restricted values show in search suggestions. Turn off indexing for that column.
- A user sees different rows on one Model. A value set for that user on that Model overrides the user's value.
How do I explain this to my team?
| Who | What they'll ask | What you can tell them |
| Security | Can a user change their own access? | No. Our backend sets each user's values in the sign-in token, and the secret key never reaches the browser. |
| Product lead | What does a new customer or region take? | Nothing per customer. The variable and rules are set up once; the token carries each user's values. |
For white label business intelligence deployments, this approach provides a scalable way to deliver customer-specific data access while maintaining a shared analytics experience.
How can I try this before I commit?
Start a free ThoughtSpot Embedded trial.
Related
这篇内容对你有用吗?
反馈只用于改善内容筛选,不等同于收藏