Role management allows users with ROLE_ADMIN, ROLE_USER_MANAGER, or ROLE_OWL_ROLE_MANAGER to manage the roles assigned to Collibra Data Quality & Observability users.
Access to different parts of the application and its functions can be restricted based on user roles, allowing users to belong to one or more roles that align with their responsibilities within your organization. This type of application security is referred to as role-based access control (RBAC), which is the method of regulating user access to the Collibra Data Quality & Observability application by the permissions granted through role assignments. RBAC is enhanced by leveraging out of the box or custom roles, particularly when combined with security settings.
In this topic
- Internal and external users
- Out of the box roles
- Security settings and user tasks
- Custom user roles
- Assigning users to roles
- Assigning user roles to datasets
Internal and external users
Collibra Data Quality & Observability supports internal and external users, who are authenticated through different mechanisms.
Internal users are those who follow the registration link on the sign in page, complete the registration form, and are approved and assigned roles by a user with ROLE_ADMIN, ROLE_USER_MANAGER, or ROLE_OWL_ROLE_MANAGER. The default Admin user account that is created automatically upon installation of Collibra Data Quality & Observability is also considered an internal user. Internal users are authenticated when they enter their Username and Password on the sign in page.
Important
When a user creates a new account and the security setting Auto approve users is disabled, another user with ROLE_ADMIN, ROLE_USER_MANAGER, or ROLE_OWL_ROLE_MANAGER must grant the new user account at least one role before the new user can sign in to Collibra Data Quality & Observability This is unnecessary when Auto approve users is enabled, because new user accounts are unlocked and have ROLE_PUBLIC by default.
External users are users of the server where Collibra Data Quality & Observability is installed. As an alternative to the basic internal user authentication method, admins can grant external users access to Collibra Data Quality & Observability by mapping external groups from authentication mechanisms such as Active Directory (AD) to Collibra Data Quality & Observability roles, which allows them to pass the authentication requirements and sign in.
Note
When an external user's associated userid object is purged from an external user store, such as AD, they can no longer sign in to Collibra Data Quality & Observability, as the system cannot locate the userid object needed to authenticate their account.
Out of the box roles
Collibra Data Quality & Observability comes with many out of the box roles designed to provide different users varied levels of access to components of the application.
Out of the box roles can be grouped into three categories:
- Admin roles: These roles have privileges to perform some system-control tasks.
- Technical steward roles: These roles have privileges to run DQ Jobs, manage rules and datasets, and view and analyze DQ Job findings.
- Business steward roles: These roles have privileges to view and analyze scorecards, but do not have dataset access when dataset security is enabled.
Admin roles
| Role | Description |
|---|---|
| ROLE_ADMIN |
Users with this role can manage connections, security and admin settings, and delegate roles. This is the only role that can delete datasets. Tip Users with this role can assign roles to other users. |
| ROLE_DATA_GOVERNANCE_MANAGER | Users with this role can create, edit, and delete business units and data categories. |
| ROLE_USER_MANAGER |
Users with this role can create and edit users and add users to roles. Tip Users with this role can assign roles to other users. |
| ROLE_OWL_ROLE_MANAGER |
Users with this role can create custom roles and assign and edit the mappings of roles to users, AD groups, and datasets. Tip Users with this role can assign roles to other users. |
| ROLE_CONNECTION_MANAGER | Users with this role can create, edit, and delete connections to data sources. |
| ROLE_DATASET_MANAGER | Users with this role can mask dataset columns and assign or edit the roles assigned to datasets on the Dataset Management page. |
| ROLE_ADMIN_VIEWER |
Users with this role can access the following Admin Console pages:
Note Users with ROLE_ADMIN_VIEWER cannot access the pages to which the quick access buttons on the Dashboards page are linked. Note Users with ROLE_ADMIN_VIEWER cannot add or delete schedule restrictions. Tip All other Admin Console pages are not accessible to users with this role. |
Users with admin roles are typically responsible for a broad range of tasks related to system control, such as the management of users, connections, and datasets. When dataset security is disabled, users with ROLE_ADMIN have unrestricted access to any part of Collibra Data Quality & Observability, including the Admin Console.
Other admin roles maintain access to major sections of the application, but do not necessarily have the global permissions that ROLE_ADMIN does. For example, a user with ROLE_CONNECTION_MANAGER can set up and test connections to data sources, but cannot create or edit datasets unless they also have ROLE_DATASET_MANAGER.
Common tasks performed by users with admin roles include but are not limited to:
- Creating and deleting connections to data sources.
- Creating and deleting users.
- Creating and deleting roles.
- Managing users.
- Assigning roles to users.
- Assigning datasets to roles.
- Creating and deleting business units and data categories.
- Enabling and disabling security options.
- Deleting datasets.
Business steward roles
| Role | Description |
|---|---|
| ROLE_PUBLIC |
Users with this role can access scorecards and reports. When the dataset security setting Dataset security is enabled, users with this role cannot access datasets. When used in conjunction with other security settings, this can be used as a "read-only" role, whereby users with ROLE_PUBLIC cannot create DQ Jobs, access or manage connections, and so on. When this role is assigned to a dataset on the Dataset Management page, the dataset is accessible to all users, irrespective of role. |
ROLE_PUBLIC holds the lowest level of privilege of all the out of the box roles. By default, all user accounts have the privileges granted to ROLE_PUBLIC when they are created, even if they are not explicitly assigned to it.
Technical steward roles
Important Many of the roles described in the table below are heavily dependent on whether corresponding security settings are enabled or disabled. As such, it is important that you are familiar with the implications of security settings before assigning these roles to users and datasets.
| Role | Description |
|---|---|
| ROLE_OWL_CHECK | When the general security setting DQ Job security is enabled, users with this role can run DQ Jobs. |
| ROLE_DATA_PREVIEW |
When the dataset security setting Require DATA_PREVIEW role to view source data is enabled on the Security Settings page, users with this role can view the following:
|
| ROLE_DATASET_TRAIN |
When the dataset security setting Require DATASET_TRAIN role for dataset training access is enabled, users with this role can train datasets. Users with this role can validate, invalidate, resolve, and retrain dataset findings. |
| ROLE_DATASET_RULES |
When the dataset security setting Require DATASET_RULES role for dataset rule create/edit access is enabled, users with this role can manage data quality rules. |
| ROLE_DATASET_ACTIONS |
When the dataset security setting Require DATASET_ACTIONS role for dataset rule create/edit access is enabled, users with this role can manage DQ Jobs from the Dataset Manager. |
| ROLE_VIEW_DATA |
Controls which users can access the DQ SQL editor to run the SQL against the database. Users with this role can view the following:
|
| ROLE_GENAI_USER | Users with this role can use SQL Assistant for Data Quality for automated SQL rule writing and troubleshooting. |
| ROLE_USER | Do not use this role, as it was deprecated. |
Users with technical steward roles are typically responsible for specific tasks, such as running DQ Jobs and reviewing their findings. Therefore, users with data steward roles often have one or more of these roles assigned to them for more granular access to these specialized tasks. For example, a user responsible for creating SQL rules to run against a dataset once it exists might have the rule writer role, ROLE_DATASET_RULES.
Common tasks performed by users with technical steward roles include all data analyst tasks, as well as the following:
- Creating, running, and terminating DQ Jobs.
- Managing dataset rules.
- Previewing data in DQ Job findings.
- Training datasets.
- Masking columns in datasets.
- Re-running and deleting scheduled DQ Jobs.
Security settings and user tasks
When the security setting Dataset security is enabled, users with roles that ordinarily have unrestricted access to datasets, including ROLE_ADMIN, must be assigned to the dataset they are attempting to access in order to access it.
When the Dataset Security setting Default owner dataset access is enabled, unless a dataset is assigned to other users, only the dataset owner can run DQ Jobs against it, view its findings, or manage its rules. Otherwise, even the dataset owner must be assigned to the dataset to access it.
Access to datasets
- When the Dataset Security setting Default owner dataset access is enabled, the creator of a dataset is automatically granted access and other users must be granted access via a role.
- When a dataset is assigned to a role, all users with this role can access it.
- When a dataset is assigned to ROLE_PUBLIC, all users can access it.
Data steward and data analyst tasks with security settings enabled
The table below shows how different security settings can restrict which roles can perform certain tasks when enabled.
| Security setting | Description | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Dataset security |
When enabled, if a user does not have a full permission role granting them the ability to perform specific tasks, they cannot perform them. The following list shows specific tasks that dataset security can prevent users without the correct full permission role from performing:
Note In the list above, a single role encompassing all tasks does not exist. Instead, multiple roles must be mapped to relevant datasets as full permission roles to allow users to perform all listed tasks. Users with ROLE_ADMIN or ROLE_DATASET_MANAGER can map roles to datasets as full permission roles on the Dataset Management page. |
||||||||||||||||
| DQ Job security |
When DQ Job security is enabled, Dataset security is disabled, and a user does not have ROLE_ADMIN or ROLE_OWL_CHECK assigned to the dataset to which they are attempting to access, they cannot create, run or schedule DQ Jobs. Similarly, when DQ Job security and Dataset security are enabled and a user has a role other than ROLE_ADMIN or ROLE_OWL_CHECK assigned to the dataset to which they are attempting to access, they cannot create, run or schedule DQ Jobs. However, when DQ Job security and Dataset security are enabled and a user has ROLE_ADMIN or ROLE_OWL_CHECK assigned to their user account and the dataset to which they are attempting to access, they can create, run or schedule DQ Jobs. Show table
|
||||||||||||||||
| Require DATA_PREVIEW role to see source data |
When enabled, only users with ROLE_DATA_PREVIEW can preview source data on the Explorer, Findings, Profile, Rules, and Dataset Overview pages. |
||||||||||||||||
| Require DATASET_TRAIN role for dataset training access | When enabled, only users with ROLE_DATASET_TRAIN can train datasets, which includes the ability to adjust the scoring model, modify thresholds of Adaptive Rules, and validate, invalidate, or resolve data quality findings. | ||||||||||||||||
| Require DATASET_RULES for dataset rule create/edit access |
When enabled, only users with ROLE_DATASET_RULES can manage rules. Note ROLE_DATA_PREVIEW is also required to manage rules. |
||||||||||||||||
| Require DATASET_ACTIONS role for dataset management actions | When enabled, only users with ROLE_DATASET_ACTIONS can edit, rename, publish, assign data categories and business units, enable integrations, and schedule DQ Jobs from the Dataset Manager. | ||||||||||||||||
| Default owner dataset access |
The default owner of a dataset is the user who created it. When enabled, this option automatically grants access to the creator of a given dataset. When this option is disabled, datasets do not have a default owner. When Dataset security and Default owner dataset access are both enabled, users with a role mapped to a dataset or the dataset owner can view, add, edit, and remove the dataset to which they are assigned or own. Note Users without a role mapped to any existing dataset can still create new datasets, view their profiles, and view, add, and remove business units from them. Additionally, when Dataset security and Default owner dataset access are both enabled, users can view, edit, and remove business units on datasets to which they are assigned or own. Note Only users with ROLE_ADMIN or ROLE_DATA_GOVERNANCE_MANAGER can create business units, which they can then add to datasets. |
Important Some tasks, such as masking columns and re-running or deleting scheduled DQ Jobs, can only be performed by users with ROLE_ADMIN and ROLE_DATASET_MANAGER, even with all of the security settings disabled.
Custom user roles
Custom roles implement Connection security and Dataset security and are intended to provide users with dataset and connection access, not operational controls.
If connection and/or dataset security are enabled, users with ROLE_ADMIN, ROLE_USER_MANAGER, or ROLE_OWL_ROLE_MANAGER should create custom roles to grant users access to specific datasets and/or connections.
When using Active Directory, you can also add custom roles as needed from the Mappings tab on the Active Directory Security Settings page.
For instructions on how to create custom roles, see Adding custom roles.
Assigning users to roles
When a new user account is created in Collibra Data Quality & Observability, it does not have any roles assigned to it by default. However, all user accounts have the privileges granted to ROLE_PUBLIC when they are created, even though they are not explicitly assigned to it out of the box. Therefore, it is best practice for users with ROLE_ADMIN, ROLE_OWL_ROLE_MANAGER, or ROLE_DATASET_MANAGER to assign new user accounts to roles to allow them to access the parts of the application relevant to them and restrict access to other parts that are not.
For instructions on how to add users to roles, see Adding users to roles.
Assigning user roles to datasets
Important This is only necessary when Dataset security is enabled.
Datasets can only be assigned to user roles, not individual users. This means that users gain access to datasets through their roles. When the dataset security setting Dataset security is enabled, users with ROLE_ADMIN or ROLE_DATASET_MANAGER can configure the roles that have access to specific datasets in Collibra Data Quality & Observability from the Dataset Management page.
When Dataset security is enabled, roles can be mapped to datasets to provide three different degrees of dataset access permissions:
- Full permission roles: Roles that grant users unrestricted access to the dataset to which they are assigned.
- Read-only roles: Roles that grant users viewer access to the areas of the application that they encompass. Users with read-only roles can also create, delete, and edit alerts, templates, and scorecards.
- Partial roles: Roles that allow any combination of Data Preview access, the ability to retrain datasets, and the ability to access the Rules page to write and manage rules.
For instructions on how to add roles to datasets, see Assigning roles to datasets.