Creating an Attribute Based Access Control Policy
We're going to create an ABAC policy that will interact with our PeopleFinder application.
Create the policy repository
First, open the Aserto Console and navigate to the Policies tab. Click on the "Create a new repository" button:
Select "Use a template":
Choose your source code provider:
Create a new policy based on the
policy-peoplefinder-abac template, and name the repo
Finally, name your policy repository
peoplefinder-abac, and click "Create a new policy repository":
Create a policy instance
After creating a policy repository, we'll create a policy instance that will be associated the repository.
First, click on the "Policies" tab and click the "Create an instance" button:
Next, you'll be asked to select between creating the policy from a sample image or from your own policy image - choose "...from your own policy image".
Next, you'll be prompted to select a policy registry:
Select "Aserto Policy Registry" from the dropdown.
Next, from the "Select organization" dropdown select your personal (account) organization.
From the "Policy repository" dropdown, select "peoplefinder-abac".
From the "Tag list" dropdown, select "latest".
This sets up the policy instance to always pick up the latest version of the policy. While this is going to be very useful while we are developing the policy - we would probably choose to lock the policy instance to a specific tag in a production environment.
Finally, name your instance
peoplefinder-abac and click "Create an instance".
Open the policy instance once it is created, and open the
As you can see, this policy is slightly different from the RBAC policy we created before: instead of referencing the
data object (which is based on the definitions in the
data.json file) and the roles defined there, it uses the user's properties to determine whether they are equal to a specific value.
In this module, we check whether the user's
department property is equal to
Operations. If the check yields a
true value, the user will be
allowed to perform the
POST operation on the
/api/users/:id resource - which means they'll be able to update the
department property of another user.
This policy will result in a dynamic behavior of the authorization model: any user assigned to the
Operations department at runtime will now have the permission to make updates to other users as well.
Let's update our PeopleFinder application to point to this new policy to see it in action.