Organization Hierarchies
Many companies need their authorization policy to correspond to their org chart.
Human resources systems, recruiting and applicant tracking systems, and customer relationship management systems all require this pattern.
To implement this, we want our authorization model to express authorization in terms of the relationship between two users.
Implement the logic
A common model for organization hierarchies is some concept of a manager or supervisor having access to the data of their direct reports.
We'll extend our typical GitCloud example to say that managers should be able to see the repositories of their direct reports.
We can use relations in Oso Cloud to implement this directly. Specifically, a user has the "viewer" role on a repository if they are the manager of the repository's creator.
actor User { relations = { manager: User, };}resource Repository { roles = ["viewer"]; permissions = ["read"]; relations = { creator: User }; "viewer" if "creator"; "viewer" if "manager" on "creator"; "read" if "viewer";}
Test it out
In our test case, Alice created a repository, and Alice's manager is Bob.
Based on those facts, Bob inherits the "viewer" role on the repository Alice created and Bob can read the repository.
test "manager can have viewer role on employees repos" { setup { has_relation(Repository{"acme"}, "creator", User{"alice"}); has_relation(User{"alice"}, "manager", User{"bob"}); } assert has_role(User{"bob"}, "viewer", Repository{"acme"}); assert allow(User{"bob"}, "read", Repository{"acme"});}