Introduction

Denodo Virtual DataPort implements a Role-Based Access Control (RBAC) model to manage permissions and enforce security. This approach adheres to the Principle of Least Privilege (PoLP), which recommends granting users only the minimum permissions they need to perform their tasks. By following PoLP, administrators can minimize the risk of unauthorized data access and simplify governance.

How Roles and Permissions Work in Denodo

Denodo allows administrators to assign permissions to users either directly or through roles, which act as containers of privileges. Assigning permissions via roles instead of individual users simplifies management: a single change to a role propagates to all its assigned users.

However, Denodo’s permission model is cumulative: a user's effective permissions are the union of all the privileges granted by their roles. While this design ensures flexibility, it also introduces a limitation—restrictions cannot override broader privileges. If one role grants access to sensitive data, that permission will remain, even if another role is designed to impose restrictions.

For example:

• A user with Role A, which grants EXECUTE privileges over a database, and Role B, which applies some restriction over a specific view in that database, will have access to the view. This is because Denodo always evaluates privileges as the union of all privileges from every role assigned to the user.

The cumulative permission model can make the implementation of fine-grained security policies difficult. Denodo implements features like the Global Security Policies (GSPs) and Tags to enforce restrictions at a global level. These features allow administrators to define rules for masking data or filtering rows and columns while relying on roles and privileges for enforcement. You can learn more about GSPs and tags in the tutorial Global Security Policies (GSPs) and tags.

NOTE: Global Security Policies are only available in Denodo Enterprise Plus.

These limitations are rooted in the way privileges are evaluated with cumulative permissions:

• The union of privileges across all roles takes precedence, meaning a single role with broader permissions can effectively nullify the restrictions imposed by a GSP.

For example:

• If a GSP is configured to mask the salary column for all users except those with the role unlock_salary, the policy will not be applied if any other role assigned to the user grants access to the view without restrictions on the salary column. The GSP cannot override these broader permissions due to the cumulative nature of role evaluation.

To address this, Denodo introduced the userRoles session attribute—a solution designed to overcome the constraints of the cumulative permission model and enable administrators to implement truly granular, attribute-based security policies.

userRoles session attribute

This feature addresses the limitations of the cumulative permission model by providing administrators with a more precise mechanism to enforce Global Security Policies (GSPs). With userRoles, policies can be applied based on the roles explicitly assigned to a user, regardless of the privileges those roles grant. ‘userRoles’ is a session attribute that contains all the roles assigned to a user during their session.

NOTE: This feature was introduced in Denodo 9.1.

How userRoles works

When a user initiates a session in Denodo, the userRoles session attribute dynamically retrieves the list of effective roles assigned to the user, including both local roles and LDAP-imported roles. This list is then evaluated during the execution of Global Security Policies (GSPs), enabling administrators to enforce access controls based on role membership rather than on privileges alone.

To begin configuring a Global Security Policy (GSP), navigate to the Administration menu in the Denodo Web Design Studio and then go to Semantics and governance > Global security policies. In this section, you can view all existing policies and create a new one by clicking on  New.

Extensive information about Global Security Policies configuration can be found in Global Security Policies Management.

Let’s see an example on how to create a GSP using the userRoles session attribute:

1. Set the Audience Scope

• Under the "Who does the global security policy apply to?" field, choose ‘All’,  this will ensure the policy applies universally, overriding any conflicting role-based privileges.

2. Define Role-Based Conditions

In the "Attributes of the user’s session" section of the GSP configuration, you can define conditions that determine when the policy should apply, based on the roles assigned to the user. To do this, use the userRoles session attribute.

The userRoles will be a list with all the roles assigned to the user in that session, we have to take this into account when defining the for the GSP.

Several operators are available to define how the condition is evaluated:

• Operators such as CONTAINS, IN, or LIKE can be used to determine whether a user has a specific role.

• CONTAINS: Evaluates to TRUE if any of the specified roles appear as substrings of the user's role list.

• Example: ["RoleA", "Role12"] CONTAINS "Role1" → TRUE (since "Role12" contains "Role1").

• IN: Checks for an exact match in the role list.

• Example: ["RoleA", "Role12"] IN "Role1", "RoleB" → FALSE.

• LIKE: Condition is satisfied if the specified pattern value matches with the attribute value from the user session.

• Example:

• userRoles IN 'unlock_salary' → The policy will apply either to users who do not have or who do have the 'unlock_salary' role, depending on how the GSP audience condition is configured.

3. Determine the Targeted Elements

• In the Elements section of the Global Security Policy configuration, you must define the scope of the policy — that is, which views or columns it should apply to. In the "What elements does it apply to?" dropdown, you have several options, including:

• All views (applies to every view in the environment)
• Views or columns tagged with any or all specific tags
• Views or columns not tagged with certain tags

By choosing "All views", the policy will evaluate every view and apply the restriction to any columns that match the configured tags. If needed, more granular targeting can be achieved using the other dropdown options to limit the scope of the restriction further.

4. Configure Restrictions

• Define how the policy should enforce access control. Some applicable restrictions are:

• Mask specific columns based on assigned tags.
• Deny execution of a view for certain users.
• Filter rows dynamically based on conditions.

By integrating userRoles within GSPs, Denodo ensures that role-based security policies are consistently enforced regardless of the broader privileges granted by other roles, solving the limitations of the traditional cumulative permission model.

Example: Role-based Restriction for Salary Column

In this example, we demonstrate how to use the userRoles session attribute to restrict access to sensitive salary data. We will configure a Global Security Policy (GSP) to mask the salary column for all users except those with the unlock_salary role.

Scenario

We have a dataset containing employee information with the following columns:

• agent_id
• agent_code        
• salary (sensitive data)

The security requirement is that the salary column must be hidden for all users, unless they have the unlock_salary role.

Challenges without the userRoles session attribute

With a traditional RBAC system and cumulative permissions, if a user does not have the unlock_salary role (intended to grant access to the salary column) but has another role with EXECUTE privileges over the view and no other restrictions, a cumulative permission model would grant full access to the salary column. This happens because permissions are evaluated as the union of all roles, and the restriction would not be enforced because one of the roles the user has grants access without any restrictions.

Implementing the restriction using userRoles

1. Assigning a Tag to the Salary Column

To enforce the restriction, we first assign a tag (limit_tag) to the salary column. This tag will be used in the GSP to define which elements are subject to the policy.

2. Creating the Global Security Policy

We configure a Global Security Policy with the following settings:

• Policy Name: salary_restriction
• Who does the policy apply to? → All users
• Attributes of the user's session → Apply the policy to users who fail to meet the condition:

• Condition: userRoles contains unlock_salary
• This ensures that the restriction applies to all users except those with the unlock_salary role.

• Elements the policy applies to → All views
• Restriction Type → Mask columns tagged with limit_tag
• Masking Behavior → Default masking (configured to hide data).

3. Expected Behavior

• Users without the unlock_salary role will see the salary column masked even if they have EXECUTE privileges coming from another role that does not impose any masking restrictions.
• Users with the unlock_salary role, will see the values of the salary column as long as they have some role that grants them EXECUTE privileges on the view and as the GSP does not apply to them.

Conclusion

Without the Global Security Policies and the userRoles session attribute, the cumulative permission model would make enforcement of global restrictions complex because privileges granted by any roles without restrictions would override the intended security policies. By leveraging the userRoles attribute within a Global Security Policy, we can ensure that the restriction is always applied allowing for true fine-grained access control.

References

Global Security Policies

Global Security Policies (GSPs) and tags

Global Security Policies Management