# Authentication and authorization

> For the complete documentation index, see [llms.txt](https://developers.thoughtspot.com/docs/llms.txt)

Source: https://developers.thoughtspot.com/docs/authorization-settings

# Authentication and authorization

User access in ThoughtSpot is determined by the privileges assigned to the groups to which they belong. Users and groups are stored locally in ThoughtSpot, even if the users are authenticated using the SAML SSO or trusted authentication method.

To provide access to ThoughtSpot content or define role-based privileges, you need to add users and groups in ThoughtSpot. You can create [user accounts](https://docs.thoughtspot.com/cloud/latest/user-management) and [user groups](https://docs.thoughtspot.com/cloud/latest/group-management) in the UI or by using [REST APIs]({{navprefix}}/{{api-user-management}}).

## How to synchronize authorization settings from external systems

The SSO method in ThoughtSpot is mostly concerned with determining who the user is (authentication). To set what a user can see and do (authorization), you will need to define access control using the features described in [Access control and data security]({{navprefix}}/{{configure-user-access}}). While an administrator can set all of these values within the ThoughtSpot UI or through direct REST API commands, you may need to synchronize authorization settings automatically from other systems within your environment.

There are three general ways to synchronize authorization settings with external systems:

-   Schedule batch sync processes to ThoughtSpot
    
-   Integrate ThoughtSpot sync commands into existing system processes
    
-   Send ThoughtSpot sync commands when an SSO user session is created
    

## User authentication and authorization

If using [SAML]({{navprefix}}/{{configure-saml}}) for SSO, ThoughtSpot can create users automatically from the SAML assertion, and add the user to existing ThoughtSpot groups.

When using [trusted authentication]({{navprefix}}/{{trusted-authentication}}), the authenticator service will use a service account with server administrator privileges. The service account can send the REST API commands to [create the user]({{navprefix}}/{{user-api}}#create-user) and [add them to the appropriate groups]({{navprefix}}/{{group-api}}#add-user-to-group) before requesting the login token.

## REST APIs for access control

Additional REST API commands can be sent to ThoughtSpot to set all of the other authorization properties beyond group membership. These commands are relevant regardless of whether you are building a scheduled sync process or setting the values when creating a user session.

### Groups and privileges

Groups have several uses within ThoughtSpot. The REST API can [create]({{navprefix}}/{{group-api}}#create-group) and [delete]({{navprefix}}/{{group-api}}#delete-group) groups for any of these purposes.

Row-level security (RLS) rules place the group name (not the display name) directly within SQL queries. To give a user a particular value within an RLS rule, you create a group whose name matches a value within the database, then assign the user to that group.

Users inherit privileges from the groups they belong to. You can define privileges at a group level when [creating]({{navprefix}}/{{group-api}}#create-group) or [updating a group]({{navprefix}}/{{group-api}}#update-group). You can also [add privilege to a group]({{navprefix}}/{{group-api}}#add-privilege) and [remove privilege from a group]({{navprefix}}/{{group-api}}#remove-privilege).

### User assignment to groups

Users must belong to groups to inherit the authentication aspects assigned to those groups. You can [add a user to a group]({{navprefix}}/{{group-api}}#add-user-to-group) individually or [add multiple users]({{navprefix}}/{{group-api}}#addMembers) to one or several groups in bulk. Similarly, you can [remove a user from a group]({{navprefix}}/{{group-api}}#delete-user-assoc) or [remove multiple users]({{navprefix}}/{{group-api}}#removeMembers) from one or several groups in a single API call.

### Share content to groups and users

Access to objects is granted as sharing rights on the object to groups and users. The [/security/share]({{navprefix}}/{{security-api}}#share-object) API endpoint allows sharing objects with users and groups, and can also restrict user access to an object.