Modify the Policy
So far, we were using a policy template created by Aserto. Now let's see how we can make changes to a policy and see how these changes make their way to the Aserto Authorizer.
Let's say our product manager has asked us to allow managers to be able to change their reports' title and department. You may naturally think that such a change would require a code change in our application. But with Aserto we can do this by modifying our policy and without making any changes to our application code! This is the power of the "Policy-as-Code" approach: it decouples the authorization logic from the application logic.
Review the policy in the Aserto Console
peoplefinder-rbac policy instance in the Policies tab again, and open the
As mentioned before, the naming convention for packages is
policyroot.METHOD.route. So in this case,
/api/users/:id route, with periods instead of slashes for a delimiter, following the Rego EBNF rules)
This module controls access to the “Update” button at the bottom of a User card, and defines the policy that authorizes users to make changes to department and title properties.
Don't confuse the this with the
peoplefinder.POST.api.users policy, which controls the ability to add new users.
Cloning the policy repository
In the Images tab, open the
Click on the
This will open a new browser window:
Copy the clone URL, open a terminal window, and do a
git clone on the URL. Open a code editor window in that repository directory. You’ll see all the modules for the PeopleFinder policy.
Let’s examine the files:
data.jsonincludes all the role definitions used by the authorizer. Any additional data can be included here, and it will be made accessible to policies under the
.manifestspecifies the policy root (in this case,
peoplefinder) as well as properties in
data.jsonthat we want to make available. In our example, the root “roles” is referenced since it is the root property in our
- All of the policies are under the
- The policies under the
__idfolder are policies for routes that have an
idpassed to them - e.g.
/api/users/:id. In the following example, we’ll modify the
The naming of the directories here is only a convention to make it easier to understand the structure of the policies, but all
.rego will be loaded into the authorizer regardless of the folder structure.
Adding a new rule
In addition to the user's role definition, we can make decisions based on the user's identity and the resource context our application can optionally send. The resource context is a key-value map that will be available in the policy as
To implement the logic of allowing managers to update their reports' title and department, we need two pieces of information: the user
id for the user shown in the user card, and the
id for the currently logged in user. In PeopleFinder, we send the selected user's
id as part of the resource context in addition to the logged in user identity. Let's add a rule that will leverage this and allow a manager in Acmecorp to update their reports' details.
Open the file
src/policies/__id/post.rego, and add the following rule to the policy:
Be sure to edit
src/policies/__id/post.rego and not
src/policies/post.rego which controls the ability to add new users.
dir.is_manager_of is part of a set of built-in Rego functions Aserto provides (you can find the full list of built-in functions here). In this case, it checks the attribute
manager of the selected user passed as part of the resource context (
input.resource.id) and determines whether it is equal to the
user.id of the logged in user.
We also need the "Update" button to be
enabled for managers, so we'll add the following rule to the policy:
This rule means that if the
enabled decision will follow whatever the
allowed decision is. That means that if any of the
allowed clauses evaluate to
true, then the
enabled decision will also be
true. Specifically, if the clause we added using the
is_manager_of built-in evaluates to
true, then the "Update" button will be
enabled - regardless of the decisions made by rules based on the logged in user's role.
The final state of the Rego file should look like the code listing below:
default allowed = false
default visible = false
default enabled = false
So now the Update operation is allowed if they have the role of an
admin or an
editor, OR if the logged in user is the manager of the employee that they are trying to update.
Push to Github
To have the policy updated in Aserto, all we have to do is to commit our changes, tag a release and push it to Github. Aserto's CI/CD pipeline will automatically create a new policy bundle and make it available to the policy instance.
git add .
git commit -m "Allowing managers to update their reports' title and department"
git tag v0.0.1
git push --tags
Back in the console, open the Policies tab and click on the
peoplefinder-rbac instance. Ensure that the new policy is reflected in the Policy browser.
Since we set the selected tag for this policy instance to
latest, Aserto will automatically update the it with the changes made to policy.
Review the behavior in the application
When you see the new policy has been updated in the policy instance, go back to PeopleFinder, and switch context to April Stewart from the top-right user context menu. This will simulate a logout of Euan and a login of his manager, April. Now the Update button is enabled, and April (as Euan's manager) should be able to update Euan's title.
If you change cards (for example, to April's own card), you'll see that the "Update" button will now be disabled. This is because
April's role is only a
viewer and not her own manager. Since no
allowed clauses will evaluate to
true, the last
enabled clause will be evaluated to
false, and the "Update" button will be disabled.
Success! You've completed the getting started tutorial, and should now be able to create and update your own policies and use them in your application. In the next section we'll explore Attribute Based Access Control (ABAC) which allows us to define a more fine-grained and dynamic authorization model.
You can also learn about how to use the Aserto OneBox to set up a local development environment.