Skip to main content

Hierarchical Permissions

The Authorizer platform can model a variety of hierarchical relationships. The hierarchy can be defined through SubjectSet rewrites or explicitly via relation tuples between two objects or using both. The following example demonstrates using SubjectSet rewrites and parent relationships to model a parent/child hierarchy.


Pretend we have an app that manages Projects and Tasks. Tasks get created under a single project. A project can have multiple tasks under it.

Let's say we have two tasks (task1 and task2) and they are children under their parent project (project1). So we have a relation tuple table that looks like this:

namespace:objectrelationsubject
tasks:task1parentprojects:project1#...
tasks:task2parentprojects:project1#...
projects:project1vieweruser1

We define two namespace configurations, one for 'projects' and one for 'tasks', as follows:

{
"name": "projects",
"relations": [
{
"name" "viewer"
}
]
}
{
"name": "tasks",
"relations": [
{
"name": "viewer",
"rewrite": {
"union": {
"children": [
{
"tupleToSubjectset": {
"tupleset": { "relation": "parent" },
"computedSubjectset": { "relation": "viewer" }
}
}
]
}
}
}
]
}

These namespace configurations express the following policies:

  • Anyone who is a viewer of a project can view the project.
  • Anyone who can view a project can view all tasks under the project.

If we issue a Check request of the form Check(tasks:task1#viewer@user1) it'll evaluate parent relationships via SubjectSet rewrites and will return a truthy outcome because project1 is the parent of task1 and project1 has a viewer 'user1'.