Attribute-Based Access Control (ABAC)

This document is intended for DBAs, developers, data stewards, and data architects who need to understand how ABAC works in ODAS.

Introduction

In role-based access control (RBAC), we create ‘roles’ that are essentially arbitrarily named collections of permissions on data. Roles generally map to users' 'roles' within the organization, for example sales_analyst, sales_director. Individual permissions on data objects such as databases and datasets are then granted to these roles, and these roles are granted to users or groups.

RBAC is useful for simplifying access control, and saves you having to create individual grants for each individual user. However as the number of users, datasets and use cases increases it becomes painful to maintain several different permutations of different objects for each role. For example if you have a sales transactions dataset that needs to be viewed differently for sales analysts in different regions, it would mean creating a role for each region i.e sales_analyst_usa, sales_analyst_emea.

Attribute-based access control, or ABAC, provides a more flexible method to define more granular access policies that prevents having to create unique roles for each granular use case, often resulting in 'role-explosion'.

The ABAC Model

ABAC provides a more flexible method to define fine-grained access control policies, leveraging "attributes" coming from several different places in the organization. There are three main categories of attributes:

  • Subject or user attributes (Who is requesting access to the data?)
  • Resource or Action attributes (What is the data being requested? What action does the user want to perform? How is it classified? What's the technical metadata?)
  • Environment attributes (e.g time and location of the request)

These attributes are evaluated and compared to ABAC access policies that set the conditions under which a requesting user will have access to some particular data.

A common example is tagging customer information with attributes such as personally identifiable information (PII), so that access is granted only to data users authorized to see it.

Managing Tags

Within Okera you can apply attributes on various data objects (databases, datasets, columns) by using tags. ODAS also includes an auto-tagging capability that can help stewards identify common, formatted data, such as phone and credit card numbers, to simplify the effort of classifying new data and writing access policies for them. Learn more about tags, such as how to create and assign them, by reading Managing Tags.

Creating ABAC policies

Policy Syntax

Okera's policy syntax allows you to specify ABAC conditions as extensions on RBAC grants in familiar SQL language. Just like RBAC grants, these ABAC policies are evaluated dynamically at run-time.

Below is a breakdown of Okera's policy syntax featuring additional ABAC clauses that are described in more detail below:

GRANT SELECT ON [CATALOG | DATABASE | TABLE ]
-- Grant access to all data objects in that scope
HAVING ATTRIBUTE [IN | NOT IN] <attributes>
-- AND objects must meet these attribute conditions to be visible
TRANSFORM <attributes> WITH <transformation_function>
-- AND transform visible columns with specified transformation functions
WHERE <condition>
-- AND only show data that matches these filters
  • HAVING ATTRIBUTE - Specify conditions to grant or restrict columns based on their tags
  • TRANSFORM - Specify any transformations on any tagged columns e.g masking or tokenization. This clause must be repeated for each new attribute transformation.
  • WHERE - Similar to the SQL WHERE clause. Use this to filter data that matches a certain condition.

Note

All additional policy clauses interact with an 'AND' operator. This means any attributes mentioned in TRANSFORM will never give access to columns if they have been previously removed by a HAVING ATTRIBUTE condition.

ABAC examples

Let's start with an RBAC grant and see how we can extend it leveraging Okera's ABAC policy conditions.

Example: Granting full read access for a table to a role.

GRANT SELECT ON TABLE sales.transactions TO ROLE sales_analysts;

Now say you want the sales_analysts role to access the same table, but only for columns with no PII data:

Example: Grant read access to columns that are not tagged security.pii.

GRANT SELECT ON TABLE sales.transactions
HAVING ATTRIBUTE NOT IN (security.pii)
TO ROLE sales_analysts;

Now say you want the sales_analysts role to access the same table, but instead of totally restricting pii columns, they can be viewed as masked.

Example: Grant read access to a table, and mask() columns tagged security.restricted.

GRANT SELECT ON TABLE sales.transactions
TRANSFORM security.restricted WITH mask()
TO ROLE sales_analysts;

Now let's say we wanted to combine both conditions above into the same policy.

Example: Grant read access to a table, restrict any columns tagged security.pii and mask columns tagged security.restricted.

GRANT SELECT ON TABLE sales.transactions
HAVING ATTRIBUTE NOT IN (security.pii)
TRANSFORM security.restricted WITH mask()
TO ROLE sales_analysts;

Example: Grant read access to a table, restrict any columns tagged security.pii, and mask columns tagged security.restricted and filter rows where country equals US.

GRANT SELECT ON TABLE sales.transactions
HAVING ATTRIBUTE NOT IN (security.pii)
TRANSFORM security.restricted WITH mask()
WHERE country='US'
TO ROLE sales_analysts;

Example: Grant read access datasets inside a database, restrict access to any objects tagged status.approved and not tagged security.pii, mask columns tagged security.restricted, and filter rows where country equals US.

GRANT SELECT ON DATABASE sales
HAVING ATTRIBUTE IN (status.approved) AND NOT IN (security.pii)
TRANSFORM security.restricted WITH mask()
WHERE country='US'
TO ROLE sales_analysts;

Creating ABAC policies in the UI

ABAC policies can be easily created by non-technical users using the Okera Policy Builder. All policies created in the policy builder are backed by Okera's ABAC syntax, so they can also be run programmatically.

To see more examples of attribute-based access control policies, as well as how to create these using the policy builder in the UI please see the Policy Examples Guide.

Attribute Scope and Inheritance

Attributes can be added to a database, dataset or a column. For the purposes of policy evaluation, if you apply a tag on an object it is implicitly evaluated as being on its descendants. For example if you apply the sales tag on a database, it means that any policies referencing that tag will see tables and columns inside that database as also containing that tag. It is not possible to apply tags on the catalog.

Note

ABAC grants only support the 'SELECT' level privilege at the database or table level scopes. See Privileges for an explanation of all the privileges and scopes supported by The Okera Policy Engine.

Validating an ABAC policy

For a GRANT statement containing an attribute to be accepted, it must observe three rules:

  • The attributes specified must exist
  • The namespace is included with the attribute name
  • The object and role do not have an existing ABAC grant referencing the same attributes (this would be redundant)

In all three cases. ODAS will throw a CatalogException explaining the rule violation. In the last case, you can edit the existing policy in the UI, see Editing Permissions.

Listing Permissions

Users can list all the permissions assigned to them by user, group, role, or tag:

SHOW GRANT ROLE sales_analyst;
SHOW GRANT USER analyst2;
SHOW GRANT GROUP analyst_group;
SHOW GRANT ATTRIBUTE security.pii on database sales;

The first example lists permissions available to the sales_analyst role. The second example lists permissions available to the analyst2 user. The third example lists permissions available to the analyst_group group. The fourth example lists permissions that reference the security.pii tag. Note that SHOW GRANT ATTRIBUTE must specific either a database or table as scope.

The output for either includes the fields:

  • Scope
  • Database
  • Table
  • Column
  • URI
  • Privilege
  • Expression

FAQs

How do RBAC and ABAC work together?

All RBAC granting functionality remains unaffected by ABAC, and you can still create new RBAC grants.

RBAC grants and ABAC grants are additive – this means they are evaluated as an 'OR'.

Since RBAC grants are not as granular as ABAC grants, if there is an existing RBAC grant on an object, it will be more permissive. For example if there is an existing RBAC grant giving access to the full table, you cannot add a new ABAC grant that specifies masking. Instead you should either revoke the existing RBAC grant and create a new ABAC grant, or edit the existing RBAC grant in the UI and add a transform condition to it. Also if you try to create a policy like the example above, the UI will throw a conflict warning. Learn more about permission conflicts here.

Does ABAC have any performance impact?

No, ABAC carries no significant performance impact - it maintains the same performance characteristics as RBAC grants.