This article gives a few examples on how you can use ABAC to provide or restrict access to users on resources.
How It Works
Role based and ABAC based access work hand in hand. The most restrictive policies among the two take precedence. If you want to provide access to the entire resource, its best to use Role based. But if the use case warrants allowing access to a subset of records or attributes on an entity for example ABAC based access control works best. To do so, we need to create policies that allow access to a subset of resource. If a data steward needs WRITE access only to an attribute in an entity in Data Studio, you also need to create policies to deny access to other entities and attributes explicitly in ABAC. It is not enough to create ALLOW policies. You also need to create policies that deny access.
Usage
Policy that allows edit on "approval" attribute on Account to DataSteward -
- Create attribute “Data Steward” resource type User, resource User . Create value for this attribute with “Account Approver, resource will be user's email
Create attribute “Account Approval” resource type Entity Attribute, resource Account.approval. Create value for this attribute with “Account Approver”
- Create Policy resource type Entity Attribute, resource Account.Approval. Condition Account.Approval.Account Approval Editor equals User.Data Steward
Policy that restricts edit all other attributes on Account for DataSteward -
- Create attribute “Account Attributes” resource type Entity Attribute, resource Account.All Attributes . Create value for this attribute with “true”
- Create Policy resource type Entity Attribute, resource Account.All Attributes. Condition User.Data Steward is empty
Testing
Note: To restrict access to other entities for this user, you need to define more policies for all entities that need restriction