In this Article
- Overview
- Permission Model
- User Assignment Process
- Accessing Role Policies
- Creating a Role Policy
- Configuring Permission Sets
- Allow and Deny Permissions
- Configuring Child-Level Permissions
- Applying Conditional Filters
- System Managed Policies
- Assigning Role Policies to User Groups
- Enable API Access for a Role
Overview
The Roles Epic introduces a permission management model in DvSum all application permissions are managed through Role Policies, providing a centralized and flexible approach to access management.
Permission Model
Role Policies now contain all application permissions and are assigned to User Groups.
The new hierarchy is:
Role Policies
↓
User Groups
↓
Users
Every permission available in the application is now controlled through Role Policies.
User Assignment Process
The user assignment workflow remains unchanged.
- Create a User Group.
- Attach the required Role Policies.
- Assign the User Group to the desired users.
This ensures users inherit all permissions defined within the attached Role Policies.
Accessing Role Policies
To manage Role Policies in the DvSum DI Application:
- Navigate to Administration from the left-side navigation menu.
- Select User Management.
- Click Role Policies.
The Role Policies page displays all available policies configured within the application.
Creating a Role Policy
To create a new Role Policy:
- Open the Role Policies page.
- Click the Add button.
- Enter a Policy Name.
- Provide a Description (optional).
- Add Permission Sets and give Permitted Actions
- Click Save.
Configuring Permission Sets
A Role Policy consists of one or more Permission Sets, which define what resources and actions users are allowed to access.
Permissions are grouped into three primary categories:
- Administration
- Assets
- Other Modules
Each category contains multiple modules that can be configured independently.
Administration Permissions
The Administration category controls access to application administration features.
Available modules include:
- Accounts
- Application Security
- Asset Types
- Custom Attributes
- Text Sets
- Job Definitions
- Job Executions
- Data Domains
- Subdomains
- Audit Log
- Data Import
- Data Sources
- Usage Analytics
Permissions can be granted at multiple levels.
For example, administrators may grant access to:
- All Administration modules
- A specific module, such as Data Sources
- Individual child components within a module
This allows organizations to provide only the permissions required for a user's responsibilities.
Standard Permissions
Most administration modules support the following permissions:
- View
- Create
- Edit
- Delete
These permissions control standard operations that users can perform within each module.
Explicit Actions
In addition to standard permissions, Role Policies include Explicit Actions, which control specific application operations.
Examples include:
- Download
- Test Connection
- Regenerate Key
- Rotate OAuth Client
- Activate
- Resend Invitation
- Catalog
- Run Profile
- Run Now
- Cancel
- Abort
Explicit Actions can be enabled independently, allowing administrators to provide precise control over operational tasks without granting full edit permissions.
For example, a user may be allowed to Test Connection for a Data Source while not being allowed to modify or delete the Data Source itself.
Asset Permissions
The Assets category controls permissions for all asset types managed within the DvSum catalog.
Asset permissions can be assigned globally or individually.
Examples of supported asset categories include:
- Database Objects
- Tables
- Views
- Columns
- Business Terms
- Data Quality Rules
- Reports
- Models
- Dashboards
- APIs
- Collections
Similar to Administration modules, each asset type supports standard permissions such as:
- View
- Edit
- Delete
Asset-specific Explicit Actions are also available.
Examples include:
- Hide
- Unhide
- Execute
- Test
- Data Classification
- View Sample Data
This granular permission model allows organizations to control both visibility and operational capabilities for each asset type.
Other Module Permissions
Role Policies also control access to several application-wide features.
These include:
- Dashboards
- Governance Views
- Lineage
- My Settings
Permissions for these modules can be configured independently based on business requirements.
Allow and Deny Permissions
Each permission within a Role Policy can be configured as either Allow or Deny.
Allow
Selecting Allow grants users permission to perform the selected operation.
For example, enabling Allow for View Data Sources permits users to view configured Data Sources.
Deny
Selecting Deny explicitly prevents users from performing the selected operation.
For example, a user may be permitted to edit a Data Source while being denied permission to delete it.
Using Allow and Deny permissions enables organizations to implement least-privilege security models while maintaining operational flexibility.
Configuring Child-Level Permissions
Role Policies support permission inheritance through parent and child modules by creating the multiple permission sets.
Instead of granting access to an entire module, administrators can assign permissions to individual child components.
For example, under Application Security, permissions can be configured separately for:
- IP Allow List
- OAuth Clients
- Integrations
- API Access
This enables highly granular permission management across the application.
Configuring Filter Conditions
To configure a Filter Condition:
- Open the required Role Policy.
- Navigate to the appropriate permission category (Administration, Assets, or Others).
- Select the resource for which permissions are being configured.
- Enable the required permissions.
- Expand the Filter Conditions section.
- Define one or more filter criteria based on the supported fields for the selected resource.
- Save the Role Policy.
Note: Filter Conditions are available only for supported resources. If a resource does not support filtering, permissions assigned to that resource apply to all instances of that resource.
Applying Filter Conditions
Role Policies support Filter Conditions, allowing administrators to further restrict access to specific resources based on predefined criteria. While permissions determine what actions a user can perform, filter conditions determine which resources those permissions apply to. This enables organizations to implement more granular access control and ensure users only have access to relevant data.
Filter conditions are configured within a Role Policy and are available for supported resources across the Administration, Assets, and Others permission categories.
Supported Resources
Filter conditions can be applied to the following resources:
Administration
Filter Conditions are supported for the following Administration modules:
- Integrations
- Asset Types
- Custom Attributes
- Data Source Types
- Tag Sets
- Job Definitions
- Data Domains
- Sub-Domains
- Environments
- Role Policies
- User Groups
- Users
- Data Sources
These filters allow administrators to limit user access to specific records within each module instead of granting unrestricted access.
Assets
Filter Conditions are supported for all Asset modules. This allows administrators to restrict access to specific assets based on the configured filter criteria, ensuring users can only view or manage the assets relevant to their responsibilities.
Others
Within the Others category, Filter Conditions are supported for:
- Governance Views
System Managed Policies
The application includes several predefined System Managed Policies that provide commonly used permission configurations.
These policies replace the default User Roles available in previous releases.
Examples include:
- Full Administration Access
- Full Asset Access
- View Access
System Managed Policies are maintained by the application and can be assigned directly to User Groups where appropriate.
Assigning Role Policies to User Groups
Once a Role Policy has been configured, it can be assigned to one or more User Groups.
To assign a Role Policy:
- Navigate to Administration → User Management → User Groups.
- Open the required User Group/ Add new User Group.
- Select the Role Policies tab.
- Choose one or more Role Policies.
- Save the changes.
All users belonging to the User Group automatically inherit the assigned permissions.
Enable API Access for a Role
Navigate to Administration → User Management → User Group.
Either add a new role or edit an existing one.
Go to the API Access tab.
Select Enable API Access.
Set a Secret Rotation Interval (e.g., 180 days) or choose Never Expires (not recommended).
-
Select the APIs this role should have access to.
By default, any APIs already available to the role in the UI are pre-selected.
Additional APIs can be enabled as needed.
Save the configuration.
Review User Group Configuration
The Review tab provides a consolidated summary of the User Group configuration before it is saved. It allows administrators to verify the assigned Role Policies, API access settings, and effective permissions inherited by the User Group.
The review page displays the following information:
- Group Name – Displays the name of the User Group being created or edited.
- Attached Policies – Lists all Role Policies assigned to the User Group.
- API Access – Indicates whether API access has been enabled for the User Group.
Permissions Summary
The Permissions Summary section provides a categorized view of the effective permissions granted through the attached Role Policies. Permissions are organized into the following tabs:
- Administration – Displays permissions related to administrative modules such as Data Sources, Data Import, User Management, Audit Trail Logs, and Usage Analytics.
- Assets – Displays permissions assigned to asset-related resources.
- Others – Displays permissions for additional application modules, such as Dashboards, Governance Views, Lineage, and My Settings.
For each resource, the following information is displayed:
- Resource – The application module or asset to which permissions apply.
- Allowed Actions – Lists the actions that users in the User Group are permitted to perform. If multiple permissions are assigned, additional actions are indicated using a +n badge.
- Denied Actions – Lists the actions that are explicitly denied for the resource.
Note: The Review tab is a read-only summary and does not allow permissions or policies to be modified. Any changes to permissions must be made from the Policies or API Access tabs before saving the User Group.
0 Comments