We have a use case that requires an approach for managing roles and permissions. In our system, there are static roles like "system-administration" that are not tied to any specific company or project. These roles should not be altered or updated except during system deployments. We also want to enable company administrators to manage their own roles and permissions dynamically. For example, "Project A" might have three distinct roles with varying access levels (admin, manager, user), while "Project B" could have only two roles, each with its own permission roles (administrator and user). These roles are specific to individual projects, but the available actions within the company and projects are predefined by us. How can we establish policies to verify role permissions for each specific project, considering that the roles are dynamic?

I reckon there are a couple of ways you could tackle this. 1. Generate scoped policies from your dynamic roles and permissions. 2. Use the dynamic roles and permissions as principal attributes, and use them in your resource policies. For approach 1, your "system" policies would be applied at the root scope. They would be responsible for the static roles and also for tenant separation (e.g. users who are members of project A are denied access to project B). Then, you'd generate scoped policies that use

DENY

rules to create more limited roles within each tenant/project. By using

DENY

rules instead of

ALLOW

at this layer, it prevents you from accidentally granting permissions that weren't granted in the root scope "system" policies. There's a (static) example of this setup here: https://github.com/cerbos/demo-multitenant-saas You'd have to build a layer that translates your roles & permissions UI into Cerbos policies and calls the Admin API to apply updates. For approach 2, you'd store the custom roles and permissions in a database somewhere and pass them to Cerbos as principal attributes, keeping your Cerbos policies static but using the principal attributes in conditions in derived roles and/or resource policies. Approach 2 is probably easier unless your dynamic roles system is very sophisticated.

Ah, the scoped policies is a good pointer, thanks. I'll read up about it. I was evaluating the second approach, and while a good approach, it does involve the added logic of the db-layer. Thanks for the info, I'll be diving into the suggestions 👍