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.


Okera's Catalog service, documented here, uses a policy-based engine to govern data access. The ODAS service uses datasets, models this data in table form so users can query the data as records (or rows). The storage format is encapsulated from view. The most common way to access data is with SQL-based queries.

When data is put under ODAS control, end users cannot see it; a data steward must grant access. Before that step, the steward first defines data in storage as a base dataset (or table). The steward can then modify the technical metadata to create an appropriate view for business users.

In role-based access control (RBAC), we organize users with a need for some data, such as quarterly sales results, into a group. We define the data they need by a table-oriented definition view so that access can be assigned to a role, such as marketing_analyst. The steward can then grant that role to one or more user groups.

Decoupling user management from access management creates a lot of flexibility. Organizing employees into functional groups is usually an operational concern. Limiting access to data to follow internal practices or maintain customer privacy is a business concern.

The ABAC Model

Attributes can be a more elegant way to identify and control data access by business meaning. For example, customer contact info can be tagged as personally identifiable information (PII) so that access is granted only to data users authorized to see it.

This approach to adding or removing columns from view gives data stewards a business-level approach to describing the data, in addition to technical controls for tokenizing or masking the data.

One use for tagging data is that it can be done soon after registering the data itself. ODAS includes an auto-tagging capability in its Data Registration tab 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.

Managing Tags

Admins can create and delete tags using the Tags tab in the ODAS Web UI. In this tab, admins first declare one or more namespaces to contain tags. The namespace can describe a function, business unit, or other organizing term that helps locate or clarify the use of its tags. A tag name can occur in each namespace only once, but the same tag name can be used in multiple namespaces. For example, both sales.kpi and support.kpi are valid tags. Consequently, fully-qualified tag names must be given when using them in a GRANT or REVOKE statement. Once a tag is created, an ODAS admin can apply it to a dataset, or columns of a dataset, using the Datasets tab of the Web UI.

The admin may also search for an existing tag in the Datasets tab to determine where it is currently applied. We strongly recommend always searching for a tag before deleting it. Bear in mind that only roles with access to the full catalog will see all the objects to which a tag has been assigned.

Granting Access with Tags

To add a tag to a GRANT or REVOKE statement, declare it by adding IN ("your tag") for the case of "any of" and "your first tag" AND "your second tag" for the case of "all of" -- to define the access for a given object.

For example, if you want the auditor role to read any column in the sample.users dataset that has been tagged security.pii:

Grant access to columns tagged security.pii:

GRANT SELECT ON TABLE sample.users HAVING ATTRIBUTE IN (security.pii) TO ROLE auditor;

Note it is still possible to grant access to all columns at once by omitting the HAVING ATTRIBUTE condition. All existing RBAC grants are not affected, and you can still create new RBAC grants. Tags are simply conditions that can be added to a grant.

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

Grant access to columns that are not tagged security.pii

GRANT SELECT ON TABLE sample.users HAVING ATTRIBUTE NOT IN (security.pii) TO ROLE analyst;

The inequality test allows the admin to express the opposite condition. In this example, the role analyst sees none of the columns the role auditor can see, and vice versa.

Admins can also use AND and OR operators to indicate all, some, or one of multiple tags must be present to grant access:

Grant access to all datasets/columns in a database that do not have one tag but do have another:

GRANT SELECT ON DATABASE sales HAVING ATTRIBUTE IN (dept.sales) AND NOT IN (security.pii) TO ROLE sales_bi;

Grant access to all datasets/columns in a database that have one or more specified tags:

GRANT SELECT ON DATABASE sales HAVING ATTRIBUTE IN (security.pii, dept.audit) TO ROLE auditor;

In the first example, both conditions must be true for the sales_bi role to read from the sales database. In the second example, the auditor role can read any object for which either condition is true.

Listing Permissions

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

SHOW GRANT ROLE sales_analyst;
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 analysts 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

The Expression field contains any attributes that have been applied.

GRANT and REVOKE Statements are Dynamic

GRANT statements take effect as soon as they have been accepted by ODAS. Any user assigned to a role that has been granted a permission may act on that permission right away. Once a permission has been revoked (or the role or data object has been dropped), the assigned users may no longer access the data.

Attribute Scope and Inheritance

Attributes can be added to a dataset or column. A tag applied to a dataset applies to all of its columns. It is not possible to tag a database or catalog. These rules are enforced through the Web UI; no other ODAS component supports the creation and management of tag attributes.


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 a GRANT statement

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

  • The attribute exists
  • The namespace is included with the attribute name
  • The object and role do not have an existing grant with any of the same attributes

In all three cases. ODAS will throw a CatalogException explaining the rule violation. In the last case, the existing grant must be revoked first. Modifying the attributes in a existing grant is not supported.

Compartmentalized Data Access

Attributes add conditions to GRANT/REVOKE statements and follow the scope of object, either dataset or column, to which they're assigned. Adding attributes to a database is not supported.

It's common to name a database for a specific business function or objective. Grouping datasets by department -- sales, marketing, administration -- is one idea. This model aligns well with role-based access control (RBAC).

While attributes complement the RBAC grant/revoke model and object-scoping, there are cases where an enterprise-wide concern, such as data privacy, can be expressed with attributes across datasets in many databases.

The attribute security.pii, for example, could be applied to datasets in all departments, but only a role with access to all metadata can see where it is used. If attribute is used in the sales database but not administration, for example, users of the administration database can't see the attribute is in use.

Attributes makes it easier to define data by its business meaning, and to integrate ODAS access controls with mature cataloging solutions that support attributes.


How do RBAC and ABAC work together?

All RBAC granting functionality remains unaffected. You can still create new RBAC grants. RBAC grants and ABAC grants are additive – this means they are evaluated as an 'OR'. If an ABAC OR RBAC grant applies on a particular object, the user will have access to it.

Does ABAC have any performance impact?

No, ABAC carries no significant performance impact. Performance is the same as with RBAC grants.