We're going to create an ABAC policy that will interact with our PeopleFinder application.
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":
Navigate to the Policies tab and click "Create a new policy instance":
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".
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 attributes to determine whether they are equal to a specific value.
In this module, we check whether the user's
department attribute 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 attributes 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.