Migrate ABAC ^BETA implementation to custom token API

Table of Contents

User properties
Migration steps
Additional resources

If your application instance is upgraded to 10.4.0.cl or a later version, ThoughtSpot recommends using /api/rest/2.0/auth/token/custom API endpoint to generate a JWT token with custom security rules instead of former /api/rest/2.0/auth/token/full or /api/rest/2.0/auth/token/object API endpoints.

For new implementations of data security using JWT tokens, refer to the ABAC via tokens documentation for guidance.

If your current application environment is using the beta version of ABAC, follow the steps described in this article to smoothly migrate your ABAC implementation from using /api/rest/2.0/auth/token/full or /api/rest/2.0/auth/token/object API endpoint to using /api/rest/2.0/auth/token/custom.

User properties🔗

In the beta version of ABAC implementation with the V2.0 Get token APIs (/api/rest/2.0/auth/token/full and /api/rest/2.0/auth/token/object), security attributes are stored in the user > user_parameters object. To avoid ambiguity during the migration, ThoughtSpot uses a different user property to store security rules and other specifications defined via /api/rest/2.0/auth/token/custom API endpoint. For all ABAC implementation with the /api/rest/2.0/auth/token/custom API workflow, the user’s security entitlement details are stored in the user > access_control_properties object as shown in this example:

[
  {
    "id": "...","name":"UserA","display_name":"User A","visibility":"SHARABLE", [...],
    "extended_properties": null,
    "extended_preferences": null,
    "user_parameters": null,
    "access_control_properties": {
      "0": {
        "ALL": {
          "filter_rules": [
            {
              "column_name": "Region",
              "operator": "IN",
              "values": [
                "West"
              ]
            },
            {
              "column_name": "state",
              "operator": "EQ",
              "values": [
                "california"
              ]
            }
          ],
          "parameter_values": []
        }
      }
    }
  }
]

Important

If the persist attribute is set as true for the beta version of the JWT tokens generated via /api/rest/2.0/auth/token/full endpoint, please set the persist_option parameter to REPLACE in your API request to /api/rest/2.0/auth/token/custom to replicate this behavior after migration.
On instances running 10.4.0.cl, the persist option for the tokens generated via /api/rest/2.0/auth/token/custom API endpoint uses the APPEND value by default, which appends the new conditions instead of replacing the existing rules. To replace the persisted attributes, set persist_option to RESET in your POST API call to /api/rest/2.0/auth/token/custom, and then send another API request with persist_option set as APPEND.
The JWT tokens generated via /api/rest/2.0/auth/token/custom do not support runtime sorting. If there are any runtime sorting rules applied via JWT tokens generated from the /api/rest/2.0/auth/token/full API call, they will be ignored during migration.

Migration steps🔗

This document assumes that you are currently using /api/rest/2.0/auth/token/full to create a JWT token to log in your users and to apply persisting security rules for user sessions in the user_parameters property of the user object.

Step 1: Enable the API workflow for the custom token endpoint🔗

Create a ThoughtSpot Support request and ask for assistance to migrate to the JWT GA API workflow (/api/rest/2.0/auth/token/custom).

Step 2: Set flags for columns and apply security rules🔗

Navigate to your Worksheets / Models and set is_mandatory_token_filter to true on columns you wish to secure via filter_rules set for ABAC.

Filter settings for ABAC token

For more information about filter_rules, see Get tokens with custom rules and filter conditions.

Step 3: Build API requests for the custom token endpoint🔗

Using a ThoughtSpot development instance, you can enable the /api/rest/2.0/auth/token/custom endpoint to test how to create new JWT token requests, as well as test the behavior for your application user.

We recommend using the REST API v2 Playground to familiarize yourself with the request payload and send test requests to demo users.

Note that an instance can only use either the JWT Beta API endpoint (/api/rest/2.0/auth/token/full or /api/rest/2.0/auth/token/object) or the JWT GA API endpoint (/api/rest/2.0/auth/token/custom) to define security rules and thus avoid ambiguity.

Step 4: Switch your workflow to auth/token/custom endpoint🔗

To schedule your migration, please contact ThoughtSpot Support. We will help you verify the functionality of the new GA API endpoint (/api/rest/2.0/auth/token/custom) for your users and disable the JWT token generation workflow with beta endpoints (/api/rest/2.0/auth/token/full or /api/rest/2.0/auth/token/object upon successful validation.

For more information about the API request and response workflow to the custom token endpoint (JWT GA API endpoint), see Get tokens with custom rules and filter conditions.

Additional resources🔗

Check the ABAC examples on the ts_everywhere_resources GitHub Repo.

Migrate ABAC BETA implementation to custom token API