# Access control and sharing > For the complete documentation index, see [llms.txt](https://developers.thoughtspot.com/docs/llms.txt) Source: https://developers.thoughtspot.com/docs/access-control-sharing # Access control and sharing Access control in ThoughtSpot is accomplished via **sharing** of content **authored** by one user to other users and groups. In practice, administrators create specific **access control groups** to grant either **read-only** or **edit** access to content, then add users to the appropriate groups. This can be done via UI, but most often is automated via REST API or JIT provisioning during SSO. Group membership also controls which users can see each other when sharing, through a property called **shareability**. > **NOTE:** Avoid using the same group for access control and roles/privileges, unless all users and groups are definitely set to NOT SHAREABLE. ## Sharing model overview The user who creates content always has access to the content they are the **author** of. The **author** of content is a single user, not a group. Authorship of content can be transferred from one user to another by an administrator account. Users other than the **author** can only view and access content if it has been **shared** to them directly or to a group they belong to. Group membership provides access to objects shared to the group with the permission level assigned to the group to all users who belong to the group. ![Shareability with groups and users](/docs/doc-images/images/shareability_access.png) Users **do not see the group** that provides them access to a given piece of content (the same content could be shared to multiple groups they belong to, or to them directly as well), nor do they see who shared content to them individually, although they can see the **author** of any content. ### Sharing content ThoughtSpot users can share objects such as Liveboards, Answers, Tables, Models, and Table columns. Sharing provides either `read-only` or `edit` permissions on an object When an object is shared, users can view all the data regardless of the permissions set at the parent object level. For example, a user can view a shared Liveboard without having access to its underlying data source from which the visualizations in the Liveboard are built. However, there are some features of a Liveboard, which do require at least `read-only` permissions to the underlying data model. ### Sharing visibility The Sharing visibility configuration allows users and groups to be set as **SHAREABLE** or **NOT SHAREABLE**. The **SHAREABLE** property of a group affects the visibility of users who belong to that group. If _UserA_ is marked as **SHAREABLE**, other users **in the same group** as _UserA_ will see _UserA_ in the **Share** dialog when they try to share an object. A user with **administrator** privileges can share any content to any user or group regardless of their visibility. This allows for using a **NOT SHAREABLE** group as an **access control group**. ![Shareability and group membership controls visibility](/docs/doc-images/images/shareability_can_share_to.png) ## Sharing via UI Within the ThoughtSpot UI, there are buttons or menu items to trigger the sharing workflow for every type of object ([Liveboards](https://docs.thoughtspot.com/cloud/latest/share-liveboards#share-liveboardpage) or [Models](https://docs.thoughtspot.com/cloud/latest/share-models) for example). ## Sharing via REST API The REST API v2 [/security/metadata/share endpoint](https://developers.thoughtspot.com/docs/restV2-playground?apiResourceId=http%2Fapi-endpoints%2Fsecurity%2Fassign-change-author) is used to programmatically share content, or to remove any access. The API request has two components, `metadata_identifiers` and `permissions`: - `metadata_identifiers` is the list of objects being shared. - `permissions` defines the set of users or groups (referred to as **principals**) being shared to, and the `share_mode` being granted. - `share_mode` can be either `READ_ONLY`, `MODIFY` (equivalent to `Edit` in the UI), or `NO_ACCESS`. ```JSON { "metadata_identifiers": [ "3f5d2d4b-87da-4f59-a144-85d444eada18" ], "permissions": [ { "principal": { "identifier": "Group A", "type": "USER_GROUP" }, "share_mode": "MODIFY" } ] } ``` To remove sharing to a user or group, you set their `share_mode` to `NO_ACCESS` in the request to `/security/metadata/share`, which effectively removes any existing `share_mode` granted to that user or group within ThoughtSpot: ```JSON { "metadata_identifiers": [ "3f5d2d4b-87da-4f59-a144-85d444eada18" ], "permissions": [ { "principal": { "identifier": "Group A", "type": "USER_GROUP" }, "share_mode": "NO_ACCESS" } ] } ``` Requests to the `/fetch-permissions` endpoints will never return any user or group that has been set to `NO_ACCESS`. ## Auditing access control Sharing details are not returned via the responses from the `/metadata/search` endpoints. Instead, there are two REST API endpoints under the **/security/** for retrieving access control details. Using the [/security/metadata/fetch-permissions](https://developers.thoughtspot.com/docs/restV2-playground?apiResourceId=http%2Fapi-endpoints%2Fsecurity%2Fassign-change-author) endpoint on an object will return the **effective permissions** for all groups and the users within those groups who have access to the object. Effective permissions for an object are the full set of groups and users who have access, and what that access level is. The [/security/principals/fetch-permissions endpoint](https://developers.thoughtspot.com/docs/restV2-playground?apiResourceId=http%2Fapi-endpoints%2Fsecurity%2Fassign-change-author) is used to get the **effective permissions** for a specific user or group. Effective permissions for a user are based on things shared to them individually and their group membership. Group effective permissions should be close to their _defined permissions_ but hierarchical groups are a feature in ThoughtSpot that would lead to more complex scenarios (hierarchical groups are discouraged when doing embedded ThoughtSpot integrations). ## Re-assign content author The **author** of any object can be re-assigned using the V2.0 [/security/metadata/assign](https://developers.thoughtspot.com/docs/restV2-playground?apiResourceId=http%2Fapi-endpoints%2Fsecurity%2Fassign-change-author) REST API endpoint: ```JSON { "metadata": [ {"identifier": "1ef11b25-9a95-4f03-9287-83010374962d"}, {"identifier": "3f5d2d4b-87da-4f59-a144-85d444eada18"} ], "user_identifier": "reports_service_account_username" } ``` Rather than re-assigning authorship, a designated **service account user** is used often when importing TML objects via REST API into a different Org or ThoughtSpot instance, establishing the user used for the import process as the **author** within that environment.