Hey Team. This is Abdullah. Have a doubt. Conside...
# permit-saas
s
Hey Team. This is Abdullah. Have a doubt. Consider there are 2 types of roles. One is on a global level (super_admin) and the other is at a instance level (project_admin). And there is a resource which is shared across multiple instances (like server resource shared between multiple instances without relation to the instance. for the sake of example, lets consider "boxes" is a resource which is shared across all instances (projects) and has no relation to one particular project). And boxes cannot have an instance role because boxes is not related to project, but is shared with multiple projects Now, Global level role can definitely access all project related resources including "boxes". If a user is assigned with an project level role, and still needs access to "boxes", What do we do? I hope it was clear šŸ˜€. But, Please ask questions if you have any
a
Hi @Shaik Mohammad Abdullah, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
Hey Abdullah! Great question about handling shared resources across instances. Based on Permit.io's model, you have a few options for this scenario: ​*Option 1: Use Top-Level Roles for Shared Resources*​ In Permit.io, roles exist at the organization level and can grant permissions across resources (1) . You could create a specific top-level role like
boxes_viewer
or
boxes_editor
that only grants access to the boxes resource (2) . Users who need boxes access would get both their project-level role AND this boxes-specific role (1) . ​*Option 2: Model with ReBAC Relationships*​ Since boxes are shared across projects without direct relationships, you could model this using ReBAC's resource roles and role derivation (3) (4) . For example: • Create a
boxes#viewer
resource role (3) • Directly assign users to this resource role when they need boxes access (4) • This keeps the access separate from project-level permissions ​*Option 3: Use Tenant-Level Permissions*​ If boxes truly belong to the entire organization, you could place them at a higher tenant level (like a "global" tenant) (1) . Users would have their project-specific roles in project tenants, plus additional roles in the global tenant for boxes access (5) (1) . The Mesa Verde demo shows a similar pattern where certain resources (like Accounts) exist at a higher level than others (5) . They use role assignments at different levels to manage this complexity . Which approach fits best depends on whether you need inheritance, how often users need boxes access, and whether you want to track boxes permissions separately from project permissions.
To learn more, see the sources I considered: [[1] Policy Basics](https://docs.permit.io/how-to/build-policies/policy-basics) [[2] Components](https://docs.permit.io/how-to/build-policies/rbac/components) [[3] Build Authorization Like Google](https://www.permit.io/blog/build-authorization-like-google) [[4] Modeling Google Drive Permissions with ReBAC](https://docs.permit.io/modeling/google-drive) [[5] Fintech / Banking Demo Application](https://docs.permit.io/modeling/mesa-verde)
s
I actually did implement option 1. Was not sure whether this was a correct approach. Thanks
a
Thanks for the feedback, glad I was helpful.
o
Salam alaikum @Shaik Mohammad Abdullah. Yes, that's a valid option.
ā¤ļø 1