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
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.
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
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 as an attribute in key-value form with a Boolean value (
false) – 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
Grant access to columns tagged
GRANT SELECT ON TABLE sample.users HAS ATTRIBUTE (security.pii=true) TO ROLE auditor;
Note it is still possible to grant access to all columns at once by omitting the
HAS 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
GRANT SELECT ON TABLE sample.users HAS ATTRIBUTE (security.pii != true) 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
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 HAS ATTRIBUTE (security.pii != true AND dept.sales = true) 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 HAS ATTRIBUTE (security.pii = true OR dept.audit = true) TO ROLE auditor;
In the first example, both conditions must be true for the
sales_bi role to read from the
In the second example, the
auditor role can read any object for which either condition is true.
Note ABAC Grants currently only support database or table scope. You cannot grant at the catalog scope.
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 analysts; SHOW GRANT ATTRIBUTE security.pii on database sales;
The first example lists permissions available to the
The second example lists permissions available to the
The third example lists permissions available to the
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:
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.
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 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.
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 catalogging solutions that support attributes. A future release will support key-value pairs with non-Boolean values.
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.