Role Policies

In this Article

• Overview
• Permission Model
• Role Policies and User Groups
• User Assignment Process
• Accessing Role Policies
• Creating a Role Policy
• Configuring Permission Sets
  • Administration Permissions
  • Standard Permissions
  • Explicit Actions
  • Asset Permissions
  • Other Module Permissions
• Allow and Deny Permissions
  • Allow
  • Deny
  • How Permissions Are Evaluated
• Configuring Child-Level Permissions
• Configuring Filter Conditions
  • Understanding Filter Conditions
• System Managed Policies
• Assigning Role Policies to User Groups
• Enable API Access for Role Policies
  • Review User Group Configuration
    • Permissions Summary
• Deprecated Features
  • Data Security Administration
  • Sample Data Exclusion Policy

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.

Role Policies and User Groups

A Role Policy defines what actions a user is allowed to perform within the application by specifying permissions, explicit actions, and optional filter conditions.

A User Group defines who those permissions apply to by grouping users with similar responsibilities. One or more Role Policies can be assigned to a User Group, and users inherit the permissions of all Role Policies attached to the groups they belong to.

Important: A Role Policy is not the same as the legacy User Role. Role Policies define permissions, while User Groups determine which users receive those permissions.

User Assignment Process

The user assignment workflow remains unchanged.

1. Create a User Group. 
2. Attach the required Role Policies. 
3. 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:

1. Navigate to Administration from the left-side navigation menu. 
2. Select User Management. 
3. 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:

1. Open the Role Policies page. 
2. Click the Add button. 
3. Enter a Policy Name. 
4. Provide a Description (optional). 
5. Add Permission Sets and give Permitted Actions
6. 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.

Default Permission 

Role Policies follow an implicit deny security model.

This means that any action that does not have an explicit Allow permission assigned is treated as denied by default.

Administrators must explicitly grant permissions for users to access resources or perform actions. If no permission is granted, users will not have access.

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.

How Permissions Are Evaluated

When evaluating user permissions, DvSum follows a default deny security model.

Only actions that are explicitly allowed through an assigned Role Policy are available to users. Any permission that has not been explicitly granted is treated as denied.

For example, if a Role Policy grants View access to Data Sources but does not include the Delete permission, users assigned to that policy can view Data Sources but cannot delete them.

This approach follows the principle of least privilege by ensuring users only have access to the operations explicitly granted through their assigned Role Policies.

Note: If a permission is not explicitly granted in a Role Policy, users will not be able to perform that action.

User Experience for Denied Actions

When a user attempts to perform an action for which they do not have permission, the application prevents the operation and displays the following message "You do not have permission to perform this action."

This message is displayed consistently throughout the application and does not reference Role Policies, User Groups, or legacy User Roles.

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:

1. Open the required Role Policy.
2. Navigate to the appropriate permission category (Administration, Assets, or Others).
3. Select the resource for which permissions are being configured.
4. Enable the required permissions.
5. Expand the Filter Conditions section.
6. Define one or more filter criteria based on the supported fields for the selected resource.
7. 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

In previous releases, DvSum included several predefined User Roles (such as Owner, Admin, Editor, and User) with fixed permission sets.

These have been replaced by System Managed Role Policies, which provide predefined permission configurations that can be assigned to User Groups.

System Managed Role Policies function similarly to the previous default roles while offering the flexibility of the new Role Policy framework.

Administrators can assign these predefined policies directly to User Groups or create custom Role Policies to meet organization-specific requirements.

Examples include:

• Full Administration Access 
• Full Asset Access 
• View Access 

Note: User Roles are no longer used for permission management. Access is now determined by the Role Policies assigned to a User Group.

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:

1. Navigate to Administration → User Management → User Groups. 
2. Open the required User Group/ Add new User Group. 
3. Select the Role Policies tab. 
4. Choose one or more Role Policies. 
5. Save the changes. 

All users belonging to the User Group automatically inherit the assigned permissions.

Enable API Access for a Role Policies

• Navigate to Administration → User Management →User Groups

• Either add a new user 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.

Deprecated Features

Data Security Administration

The standalone Data Security Admin role has been incorporated into the Role Policy framework.

Instead of assigning a dedicated Data Security Admin role, administrators can now create or assign a Role Policy that grants the required permissions for managing data security operations.

These permissions include capabilities such as:

• Hiding and unhiding tables and columns
• Managing Data Classification
• Viewing Sample Data
• Deleting tables and columns (where applicable)
• Other security-related actions controlled through Explicit Actions

This centralized permission model provides greater flexibility by allowing organizations to grant only the specific security permissions required, rather than assigning a dedicated administrative role.

Sample Data Exclusion Policy

The Sample Data Exclusion Policy has also been integrated into the new authorization framework.

Previously, Sample Data Exclusion Policies were configured separately and assigned to User Roles to restrict access to profiling sample data and Data Quality exception records.

In the new model, these restrictions are managed through Role Policies using Filter Conditions and permission assignments.

Filter Conditions can be configured to restrict access based on supported criteria such as Data Sources, Data Domains, Asset Types, and other supported resources, allowing administrators to implement fine-grained access controls while maintaining a centralized permission model.

This unified approach simplifies permission management by consolidating application permissions, data visibility controls, and security policies into a single authorization framework.