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.

../../_images/Diagram_1.png

Access to Functionality

Roles

When you first join Alation, you are assigned a user role. There are 6 roles:

../../_images/Diagram_03.png

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:

../../_images/Access_01.png

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:

../../_images/RolesVR6_01.png

Your role will be displayed under your display name:

../../_images/RolesVR6_02.png

Hats

Applies to releases before 2020.3

Note

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:

../../_images/Access_02.png

And here’s the view for a user wearing the Curator hat:

../../_images/Access_03.png

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.

See Access Tab for more details about access settings of data sources and Roles Overview V R7 (5.12.x) and Newer for information about roles.

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:

../../_images/Access_04.png

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:

../../_images/Access_05.png

There are several ways Data Source Admins can control access to data:

Per-Object Parameters

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:

../../_images/Access_06.png

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:

../../_images/Access_07.png

Sensitive columns in the Sample Content table on a table object page:

../../_images/Access_08.png

Dynamic Profiling

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:

../../_images/Access_09.png

For help working with credentials, see Working with Data Source Connections.

Obfuscate Literals

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 :

../../_images/Access_10.png

Obfuscate Literals ON :

../../_images/Access_11.png

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:

../../_images/Access_12.png

This ensures that users only retrieve data they are granted access to on the database.