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
Click the peoplefinder-rbac
policy instance in the Policies tab again, and open the peoplefinder.POST.api.users.__id
module.
As mentioned before, the naming convention for packages is policyroot.METHOD.route
. So in this case,
policyroot
ispeoplefinder
METHOD
isPOST
(signifying anHTTP POST
method)route
isapi.users.__id
(signifying the/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 peoplefinder
repository:

Click on the https://github.com/[user]/policy-peoplefinder-rbac]
link:

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.json
includes all the role definitions used by the authorizer. Any additional data can be included here, and it will be made accessible to policies under thedata
object..manifest
specifies the policy root (in this case,peoplefinder
) as well as properties indata.json
that we want to make available. In our example, the root “roles” is referenced since it is the root property in ourdata.json
file.- All of the policies are under the
policies
directory. - The policies under the
__id
folder are policies for routes that have anid
passed to them - e.g./api/users/:id
. In the following example, we’ll modify the__id/post.rego
policy.
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 input.resource
.
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:
allowed {
dir.is_manager_of(input.user.id, input.resource.id)
}
Be sure to edit src/policies/__id/post.rego
and not src/policies/post.rego
which controls the ability to add new users.
The expression 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:
enabled {
allowed
}
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:
package peoplefinder.POST.api.users.__id
import input.policy.path
import input.user.properties
default allowed = false
default visible = false
default enabled = false
allowed {
some index
data.roles[properties.roles[index]].perms[path].allowed
}
allowed {
dir.is_manager_of(input.user.id, input.resource.id)
}
visible {
some index
data.roles[properties.roles[index]].perms[path].visible
}
enabled {
some index
data.roles[properties.roles[index]].perms[path].enabled
}
enabled {
allowed
}
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 push
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.
Next Steps
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.