Attribute-Based Access Control (ABAC) and Global Security Policies in the Denodo Platform

Reading Time: 7 minutes

Data is one of the most valuable assets for any organization. To protect sensitive information, you need to not only verify the authenticity of the individuals trying to access that data, but also selectively restrict access to data assets that reside across multiple cloud and on-premises environments.

Data access control is a fundamental security capability that enables companies to control data access through the definition of a set of policies. By implementing robust security policies, companies can keep personally identifiable information (PII), intellectual property, and other confidential information from getting into the wrong hands, internally or externally.

Security policies enable organizations to grant users the right privileges with which to access data assets. These policies should rely on the Principle of Least Privileges (POLP), i.e. the minimal access privileges necessary for their jobs.

To build consistent security policies, you need to leverage two fundamental components:

1. Authentication: The verification of the user’s identity
2. Authorization: The definition of which data assets the user can see and all related limitations on visibility and actions that the user is able to perform on those assets

The two main data-access-control models are role-based access control (RBAC) and attribute-based access control (ABAC). RBAC is the traditional model, which enables the definition of access privileges based on the user’s roles: when a person changes responsibilities, jobs, or functions, the administrator assigns that user a new role with different access privileges.

In recent years, the traditional RBAC model has been enriched and eventually overcome by the ABAC model. ABAC is more dynamic and flexible, and it is based on the concept of user attributes.

In ABAC, a user’s authorization to perform a set of given operations is determined by evaluating a set of key attributes associated with the user, dataset, and, in some cases, environmental attributes. This is essentially the What, Where, and Who of a specific user session; with ABAC, administrators have a better, more fine-grained control over privilege assignment. Unlike RBAC, which simply defines roles with specific sets of privileges, ABAC can express complex rule sets incorporating many different attributes. Through the definition of consistent user and dataset attributes into security policies, ABAC eliminates the need for explicit authorizations to users and roles needed in a non-ABAC access method, reducing the complexity of managing access lists and groups.

ABAC Model Development, Simplified

The Denodo Platform enables administrators to fully implement ABAC data-access-control models in their organizations. Administrators can define a set of user attributes whose values are retrieved from the Identity Provider used in the authentication step. In the Denodo Platform, administrators can assign any view and column of virtual databases to tags (dataset attributes), and then they can restrict access to data or mask certain data defining global security polices based on roles, session attributes, and tags.

Let’s see how this works in the Denodo Platform in more detail and learn more about what security administrators have to do.   

Imagine a scenario in which users log into the Denodo Platform with LDAP, Kerberos, or OAuth protocols, or with a Denodo Security Token. Session attributes can be defined and made available for developers with a simple configuration in the Virtual Data Port (VDP) server.

In this scenario, assume that multiple users will access the Denodo Platform. These users can be categorized into two main groups based on their Organization attribute: Internal or External. Each user has specific roles assigned to them, such as Manager and Analyst. Finally, these users are based out of different countries and belong to different company divisions.

An administrator can then take advantage of these attributes and create a global security policy so that anyone from an external group will have limited access to PII data (using redaction technique for example) across all data sources.

The requirement is to restrict access to the data based on user criteria like user type, role, and country.

Restricting data access based on these specific criteria can be a demanding task for administrators. Traditionally, this has been addressed using RBAC, which involves creating numerous roles and applying distinct restrictions for each role. However, as the number of roles increases, this approach can become cumbersome and challenging to manage.

ABAC offers a more efficient solution to tackle complex data access scenarios. When applied in the Denodo Platform via global security policies (GSPs), ABAC simplifies restriction management. With ABAC, administrators can control data access on a global scale, minimizing the need to create multiple roles with specific restrictions for each user. This approach streamlines the implementation and management of access controls.

To elaborate more on this scenario, let’s assume that single sign-on (SSO) was configured in the Denodo Platform using an external identity provider (for instance Okta using SAML/OAuth). In this identity provider, each user has specific values of its attributes as depicted in the image 1 (organization, division, and country). Once the user is authenticated, the Denodo Security Token will carry all the user attribute values, and the security administrator has just to define, in Denodo Design Studio, a set of session variables to which to map the corresponding user attributes.

The Denodo Platform provides developers with VQL functions, to retrieve session attribute values during the development of integration processes or the definition of security policies.

Proceeding with our scenario, before defining a security policy, we have to define a set of tags to be used afterwards. In our example, we will define a GSP on a bv_customer view belonging to a db_test_abac virtual data base: tags, such as master_data, customer_id, country, and sensitive, have been created and assigned to the views and their columns.

Tags are very useful objects on which to base the definition of a GSP: They add much more flexibility (simply by adding views and columns to the tags the security administrator can extend the application of the GSP to this data), they speed up the implementation of security rules, and they reduce the possibility of making errors during definition.

Now that we know how to leverage the values of user session attributes, and we have created all the necessary tags, we can conclude our scenario with the definition of three GSPs. Let’s suppose that we want to restrict access to our users in three ways:

1. Users of both Analyst and Manager roles can view only the rows of the customer master data in which the customer’s country match the user’s state attribute value.
2. For users of both Analyst and Manager roles that belong to the division Marketing, the field customer_id of the customer master data has to be masked with a hashing function.
3. Users of both Analyst and Manager roles, External to the organization, can’t view any row of the customer master data.

To implement these requirements, we will define 3 different GSPs that use tags and session attributes. The Denodo Platform provides a user interface for creating GSPs, in which administrators can select the role or set of roles to which the policy has to be applied and the list of data objects to be restricted by means of tags. Administrators can then further specify the perimeter of the policy using user attributes and define the restriction rule.

To better understand how a GSP may be easily defined in Denodo, let’s take a closer look at the 3 policies that were just created in our scenario. In each of these GSPs we implement an ABAC model, because we use session attribute values to control data access.

GSP#1: The GSP country_segmentation  enables users of both the Analyst and Manager roles to view only the rows of the customer master data (in our example, the view bv_customer tagged as master_data) where the value of the customer’s country (field c_birth_country of bv_customer  table, tagged as country) match the value of user’s session attribute country.

GSP#2: The GSP hash_customer_id specifies that for users of both the Analyst and Manager roles that belong to the division Marketing (session attribute division=Marketing), the field customer_id (tagged as customer_id) of the customer master data (in our example the view bv_customer tagged as master_data) has to be masked with a hashing function.

GSP#3: The GSP restrict_external_users denies access to customer master data (in our example the view bv_customer tagged as master_data) for users External to the organization (session attribute organization=External) and for users of both the Analyst and Manager roles.

Easy, Robust Security

In this post, I hope I showed you how easy it is to implement ABAC data-access-control policies in the Denodo Platform. ABAC has several benefits compared with RBAC: It can handle more complex, dynamic scenarios in which access decisions depend on multiple factors and conditions. ABAC can also support finer-grained access control, which establish different levels of access to different resources or actions within the same role.

With GSPs and tagging functionality, the Denodo Platform enables administrators to develop ABAC models with greater speed, flexibility, and accuracy.