Hi! Could someone help me find a correct implementation for the following case? Let’s say we have the following hierarchy: Group A Group B Resource 1 Group C Resource 2 Groups and resources share the same permissions: * A group/resource can have one owner * A group/resource can have one or more editors * A group/resource can have one or more viewers Nesting can possibly be deeper. Users can create groups and resources dynamically. If a principal is an owner of

Group A

, it owns all lower groups/resources. So in the example, it also has an ownership role of

Group B

,

Group C

,

Resource 1

and

Resource 2

We currently use Authzed as a relational permission system. But we are investigating other solutions because we want attribute-based permissions in the near future and came across Cerbos! I’m aware of the hierarchy functions, but we’re struggling with the correct way to represent the above. Could someone point us in the right direction?

Hi. So, usually how hierarchies are used in Cerbos is by sending the hierarchy membership information for both the principal and the resource and writing rules that check for overlaps between those two. Say, for example, user Alice is an editor of Group B and owner of Group D. She's trying to access resource X which is under

Group A > Group B > Group C

. In the request to Cerbos, the principal (Alice) would have the attributes

editor: ["A.B"]

and

owner: ["D"]

while the resource (X) would have

member_of: "A.B.C"

. A Cerbos policy rule could then infer that Alice is an editor of X because there exists a value in

request.principal.attr.editor

that is an

ancestorOf

the

request.resource.attr.member_of

attribute. Now, if your system has unlimited, dynamically created hierarchies, doing the above is probably not very practical. Since you're already using a Zanzibar system (Authzed), it makes sense to resolve those relationships using that because it is optimized for solving that particular problem. Where Cerbos fits in is at the last stage after the relationships are established. Sure, the user is an editor of the resource. But, are they editing the resource from a trusted network? Are they accessing the resource during working hours? Are they trying to edit a resource that is classified as sensitive? This sort of attribute-driven, contextual decision making is what Cerbos is excellent at. Those kinds of decisions are hard/impossible to model with Zanzibar alone. There's a good synergy between Zanzibar-based systems and Cerbos because they complement each other in areas that they are not strong in. So, it doesn't have to be an either/or decision. It could be both.

Hi Charith, Thanks for the response! How many dynamic hierarchies are feasible do you think? In our use case, users have access to maybe max 10 groups 3 levels deep, this would be the extreme case. Most users will have 1-3 groups with a depth of 1. What are your thoughts performance-wise? We would rather use one service than two on the operations side 🙂

Hi Robert. Those numbers seem totally reasonable and I don't think they would pose any problems for Cerbos. I'd only start worrying if the number of groups that a user has access to goes up to hundreds or thousands because then the requests to Cerbos will start to get quite large and unwieldy. I don't know too much about your system requirements so the naive solution I came up with above is O(num_groups x num_levels) at the worst case. There are probably cleverer ways to model it given a deeper understanding of the system requirements. For example, it might even be possible to traverse the hierarchies directly in your database using SQL and just sending that as another attribute of the request to Cerbos. That way, you don't have to replicate the complex relationship logic in Cerbos policies and just focus on the ABAC side of things.

Oke thanks Charith! I’ll look into the traversing directly in the database, your help is much appreciated!

Happy to help. Let us know how you get along with your research.

Will do 👍