Access, Roles, and Permissions¶
Applies from release V R3 (5.6.x)
Roles, permissions, and various access rules usually define what a user is allowed or denied in a software product. In Alation, there are several factors that control what you can see and what you can do in the Catalog.
To control access to functionality, Alation has roles. To control access to Catalog objects, there are privacy settings applicable to specific objects or inherited from the source database or BI platform. There are also custom field permissions that define a user’s ability to edit custom fields. Field permissions can be applied to individual users or groups.
Access to Functionality¶
When you first join Alation, you are assigned a user role. There are 6 roles:
Your user role is the primary access rule that determines what pages you see in the Catalog and what actions you can perform. For example, as a Server Admin, you will be able to access the Admin Settings page, which other roles cannot do. As a Catalog Admin, you can create and manage Catalog sets and custom field permissions, which a Viewer cannot do. If an action in Alation is not allowed because your role does not grant permission for it, certain parts of the interface will appear inactive and you will see an insufficient permissions message on hover-over:
What Role Do I Have?¶
You can check your current role in your User Profile.
On the upper right, hover over the user avatar and in the menu that opens, click User Profile:
Your role will be displayed under your display name:
Applies to releases before 2020.3
In release 2020.3 and newer the Hats feature is no longer available.
If enabled in your Catalog, Hats are a way to slightly change the layout of the main toolbar to make some features more accessible to you depending on your primary tasks in Alation. Namely, hats will make either Compose or the Data Stewardship features more accessible to you from the main toolbar. Note that Hats do not control access to features, but they do impact the layout of the controls you see on the main toolbar. For example, here is how wearing the Analyst hat changes the main toolbar:
And here’s the view for a user wearing the Curator hat:
Hats do not change your Alation user role in any way. They only help you access either the Compose or the Stewardship features quicker from the main toolbar.
Access to Objects¶
Access to Data Sources and File Systems¶
Access to data sources and file systems can be controlled for each individual source and granted to individual users. Whether or not you can view a data source or a file system source in Alation depends on their visibility settings.
Data sources and file system sources can be public (visible to everyone) or private (visible only to users who were granted access).
To be able to work with the settings of a data source and run the data jobs you must be granted the Data Source Admin function for a given data source.
To be able to work with the settings of a file system source, you must be granted the File System Admin function. Privacy settings of file systems are available from version 5.12.3. Refer to Access to File Systems for more details.
Access to Tables¶
From release 2020.4, in the Alation Catalog, user access to Table objects can be controlled separately from access to the parent Data Source: permissions to view a table can be set for a specific table object. Users can only view the Table objects that they have the access permissions for. Table privacy can be enabled on your instance by a Server Admin. For details, see Table Privacy Settings.
Access to Articles¶
Articles have access settings of their own. You can make your article private and not findable by other users in Search; you can share it with specific users or keep it public and accessible by everyone in Alation. Your ability to find and read an article in your Catalog depends on the access settings for this specific article: Grant Access to Articles.
Access to Queries¶
Query objects have access settings too. Whether or not you can find a query using Search and view it depends on whether or not you have access to the underlying data source. Whether or not you can edit a query, depends on your access rights to this individual query. Currently, all users can find queries for data sources they can access using Search. If anyone shares a query on a data source that you do not have access to, you will see the 403 error (access denied) when you try to view this query following the shared link.
If you have access to a data source, you can view both published and unpublished queries on this source; but to be able to contribute to a query, you need to explicitly request the Edit access.
Access to BI Objects¶
For BI sources in Alation (for example, Tableau sources), Alation will attempt to establish a match between Alation users and the BI system users so that the view permissions for extracted BI objects can be extracted into Alation too. If Alation cannot find a BI user match for an Alation user, this user will not be able to view the extracted BI objects. For more information about permission mirroring for BI sources, see, for example, Permission Mirroring for Tableau.
Visibility Settings Using Manual Catalog Sets¶
Sometimes Catalog Admins may choose not to include specific data objects into Search results using visibility settings in manual Catalog sets. This is another reason why specific objects may be hidden from Search.
Access to Catalog Fields¶
Custom Field Permissions¶
Whether or not users can edit custom fields on data objects as part of the curation effort can be controlled with custom field permissions. If the editing capabilities on a field on a data object page appear disabled to you, this means field permissions are enforced and editing may only be allowed for a specific group of users:
Access to Data¶
Alation provides the ability to view a small sample of real data in the Catalog. This means Catalog users may see examples of real data on the respective pages of tables and columns under Samples:
There are several ways Data Source Admins can control access to data:
It is possible to specify which data objects should not be browsable using the Catalog Browser (the left-hand navigation panel) and should not be sampled. To do so, an admin can use the settings on the Per-Object Parameters tab of a data source settings page:
Sensitive Data Setting¶
It is possible to mark data as sensitive on the column level, on the Per-Object Parameters tab. Values of sensitive columns will not be sampled:
Sensitive columns in the Sample Content table on a table object page:
An admin can turn on Dynamic Profiling on the General Settings tab of a data source settings to require users to enter their own credentials before they can run a table or a column profile. They will only be able to see the data they have access to on the database. Sample data will only be visible to the user who performs profiling:
For help working with credentials, see Working with Data Source Connections.
You can turn on Obfuscate Literals on the General Settings tab of a data source settings so that literal values in ingested queries are not shown in the UI. Instead, users will see placeholder values.
Obfuscate Literals OFF :
Obfuscate Literals ON :
Access to Compose¶
In Compose, before users are able to run queries on a data source and retrieve any real data, they will need to authenticate with their database credentials:
This ensures that users only retrieve data they are granted access to on the database.