Sharing connections
Last updated
Last updated
Connections can be shared across the organization so that other users can also use and access the data in CARTO. To share a connection, navigate to the Connections section of the Workspace and click on the Permissions and sharing option in the connection card. This will open a modal where you will see the different sharing modes.
Connections in CARTO have two possible sharing modes:
Private: the connection can only be viewed, used, and edited by you. When you create a connection, it’s always private by default.
Shared: other users in your organization can view and use the connection, but only you can edit it. You can further restrict this shared mode using one of the following options:
Entire organization: all users in your organization can view and use the connection (to build a map, for example). This is option is disabled for OAuth connections.
Specific groups: this lets you manually select which user groups can view and use this connection. This option is disabled for OAuth connections.
Viewer credentials: this option is similar to Entire organization, but requires all users, regardless of their role, to authenticate using their own credentials to view and use the connection.
Not all sharing modes are available for all connections. For example, you need to use Single Sign-On and Groups to select the Specific groups option; and Viewer credentials is only available for BigQuery (OAuth), Snowflake (OAuth) and Databricks connections. On the other hand, OAuth connections can only be be shared while requiring viewer credentials.
You can still create public maps using private connections and connections that require viewer credentials. The public map will retrieve the necessary data without exposing any credentials.
The Viewer credentials option on shared connections allows connection owners to require other users to authenticate using their own credentials to access the shared connection. This option can be used to leverage policies such as Row-Level Security or collaborate in maps while using personal credentials. Requiring viewer credentials is available for:
BigQuery OAuth connections (using "Sign in with Google")
Once this option is enabled, users attempting to access data through that connection —such as when consuming maps, running workflows, or navigating the data explorer— will be required to authenticate with their own credentials.
After authenticating, users will be able to use that connection as usual, in accordance to the access policies set in the Data Warehouse.
Users can add their individual credentials to a connection that requires viewer credentials in three places:
Data explorer: opening a shared connection that requires viewer credentials will prompt the user to authenticate.
Map builder: opening a map that uses a connection that requires viewer credentials will prompt the user to authenticate.
Connection card: Users can add their credentials by clicking on the three dots of a connection card and clicking on Add my credentials.
Individual credentials will be stored as long as they're valid, so users won't need to re-enter them each time they use the connection.
Cache management is specific to each user when viewer credentials are required. One user will never be able to access another user's cached data.
Individual credentials may be removed at any time. There are two places from which you can do this:
Map builder: click on the three dots at the top right corner and then select Remove credentials.
Connection card: click on the three dots of the connection card and then select Remove my credentials.
Users that wish to reintroduce their credentials (because they changed or expired, for example) need to remove them first and then reauthenticate.
Requiring viewer credentials on a connection makes it possible to leverage security policies set in the database, such as Row-Level Security policies.
With Row-Level Security policies, it is possible for two different users to see two different versions of the same table, depending on the role-based permissions set by the organization. This way, control remains centralized in the Data Warehouse.
We recommend to set security policies at the database level. For more information, feel free to reference the following resources:
