Hi, I'm trying to figure out if Cerbos is a good fit for us. We have quite a complicated parent/child resource hierarchical structure (and simple user permissions), I can see that hierarchical structures are supported in the docs but I'm really sure if I'm barking up the wrong tree.
Alex Olivier (Cerbos)
06/26/2023, 10:31 PM
Hi Toby - we have lots of users which have a similar model. The way to approach this is dependant on how/where you store the hierarchy and passing it into the principal/resource attributes - if you can define a structure that works then it is relatively simple to traverse the tree in policy conditions
I think our primary complication is that the permissions inherit down our resource tree, so I would expect that we would need to separately maintain the tree structure rather than passing it with each request (I don't think that's scalable with our dataset, 1000+ items to be evaluated). I did see some kind of tag parent structure in the docs but haven't made it back to that page yet.
Thank you for getting back to me 👍
Alex Olivier (Cerbos)
06/26/2023, 10:51 PM
The Cerbos approach to this is to remain stateless rather than having to synchronise state between your source of truth and the authorization layer. In the scope of the request by a user you generally already know who they are from the authentication process so the overhead of passing it through to Cerbos doesn’t usually has as much overhead as one would think - but obviously that is architecture is dependent.
The stateless approach to Cerbos was an early design decision primary for performance and latency. When there is state to be maintained, not only have you go to ensure it is up to date with near-zero log but also have to worry about scaling the data store itself. Being stateless means you can horizontally scale Cerbos instances or use something like a sidecar pattern if you are in k8s etc. As the PDP doesn’t need to query a data store on each check, each request is completed purely in memory meaning extremely low latency which is critical for AuthZ checks as these are in the blocking path of every single request to your app and can’t be cached unlike an AuthN token.