👋 @Joned Sarwar Thank you for joining us. What is your use case? How can we help?

Hey @Emre (Cerbos) great to be here 😃 We’re looking for an authz framework for our web app. Currently it consists of a single type of resource but users can have different permissions on different resource ids (eg share a specific resource id to another user as read-only or read-write). Can't quite get my head around how this type of use case can be achieved in Cerbos, other than storing that assignment in our own db and then passing it in as an attribute on resource or user. Or potentially creating new policies for each assignment. I can see how to do it in a Zanzibar-like system but not a fan of replicating users and groups (would much rather use attributes). What's the right way to think about this?

Hey the model you have suggested is the recommended approach - passing the context about the user access as attributes and using Cerbos policies to make the decision (as you may want to enforce other conditions based on other attributes later). We similarly aren't a fan of replicating user info anywhere hence Cerbos solely from the data provided at request time to make the decision which ensures there is no risk of stale caches or getting out of sync with the source system

If you sent the list of resources a user has access to as part of the principal, along with their access level, and then the resource ID and any other details as the resource, the policy will be very easy to write

Thanks for info. That makes sense, though if the policy is so simple I wonder why should I use a separate service for it?

Because these things never stay simple? 😅

Indeed! We actually gave a talk about this at DeveloperWeek Europe (video, article) - what can start out as a simple if/else statement can end up a tangled mess (one I’ve made many times!) especially if you scale out to micorservices, sell to enteprise with complex org requirements or go for compliance certs. It has taken me a whole engineering squad for 3 months to do this in a supply chain business before - something I never want to do again, hence Cerbos!

one fairly simple use-case that comes up fairly often, and can already be a pain with if/else checks… allowing a resource owner to manage the roles of the resource, including adding other owners, but not allowing them to edit their own role if they’re the last owner… that was a super-simple policy to write in cerbos, and didn’t need any extra code checks because the info was all there anyway for other policies:

- actions: ['edit']
      effect: EFFECT_ALLOW
      derivedRoles:
        - resource.owner
      condition:
        match:
          expr: P.id != R.attr.userId || size(R.attr.resource.ownerIds) > 1