Hi Team, We have need to implement a simple RBAC + ReBAC access control model and I'd like to validate the approach and design. Our Use Case I have a system with organizations, and each organization contains projects and users. Every user in an organization is assigned the member role by default. Members are allowed to create projects. Each project has its own project-level roles: - project_admin - project_member When a user (who is an member) creates a project, they automatically become the project_admin for that specific project. A project_admin can: Add or remove project_members Add or remove project_admins Current Permission Model Resource Types - project Roles - member - project#project_admin - project#project_member Each role has specific allowed actions on the resource types. Example permission check:

{
  "user": {
    "key": "user_id1"
  },
  "action": "create",
  "resource": {
    "type": "project",
    "tenant": "default",
    "key": "project_test10"
  },
  "context": {}
}

Is this RBAC + ReBAC design and resource-instance model valid for Permit.io for this use case? Any other design options/candidates that you'd recommend? In the first iteration, we'd like to use the cloud PDP exclusively without a local PDP setup. Is there a another approach where this kind of permission model can be supported by exclusively using cloud PDP?

Hi @Mihiru Kongahage, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.

Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?

Your RBAC + ReBAC design looks solid for Permit.io, but there's an important limitation with the Cloud PDP that affects your plan. Cloud PDP Limitation The Cloud PDP does not support ReBAC policies (1) (2) (3) . This is explicitly stated in the documentation: "For time being, the cloud PDP is not compatible with Attribute-based Access Control policies (ABAC) and also Relationship-based Access Control policies (ReBAC) " (2) (3) . Since your model uses resource-specific roles like

project#project_admin

and

project#project_member

, which are ReBAC patterns, you'll need to deploy a local PDP container to support this design (4) (5) . Your Design Validation Your approach using resource roles is exactly how ReBAC should be implemented in Permit.io . Resource roles are formatted as

Resource#Role

, which matches your

project#project_admin

and

project#project_member

pattern . For the automatic role assignment when a member creates a project, you can use role derivations to automatically grant the creator

project#project_admin

permissions (5) . Alternative for Cloud PDP Only If you must use Cloud PDP exclusively in your first iteration, you'd need to simplify to pure RBAC without the resource-specific roles. This would mean using flat roles like

admin

and

member

at the organization level only, which significantly limits your granular project-level permissions. Recommended Approach Deploy the local PDP container - it's straightforward to set up (2) (3) :

docker run -it -p 7766:7000 --env PDP_DEBUG=True --env PDP_API_KEY=<YOUR_API_KEY> permitio/pdp-v2:latest

Then initialize your SDK to use the local PDP (2) :

const permit = new Permit({
  pdp: "<http://localhost:7766>",
  token: "[YOUR_API_KEY]",
}) ;

This enables your full RBAC + ReBAC model with project-level roles and relationship-based permissions.

Answered in #C02TVG7RY1X