https://linen.dev logo
Join Slack
Powered by
<@U08614ZV82F> I have a multi tenant platform wh...
# permit-saas
s
@Ask Inkeep I have a multi tenant platform where we have the platform and the tenants and then tenants have multiple clients. There are going to be resources the platform manages, which can be view only for the tenants and their clients. There are going to be resources the tenants own, clients being one. There are going to be resources that clients own. The clients will have read access to tenant specific resources too. There are 3 types of users right now the platform admin, the tenant admin and client admin. The tenant admin manages all the clients in that tenant. The client admin has access to its clients resources. We also have tenant admins with access to only selected clients even though the tenant has other clients. What is the best approach to model this with permit? Will RBAC work fine? With the rebac approach having to sync every resource being created is not ideal, or if there is a way around it? How can we solve the effectively where every resource created/updated does not have to be synced. Give me options and help me out.
a
Thanks for tagging me @sarin regmi. I'll look through relevant sources and get back to you shortly.
This is a complex hierarchical multi-tenant scenario. Let me break down your options: ​*Your Hierarchy:*​ • Platform → Tenants → Clients → Resources • Users: Platform Admin, Tenant Admin (full or partial client access) , Client Admin ​*Option 1: RBAC with Multiple Tenants*​ RBAC can work for simpler cases. You'd model each "client" as a Permit tenant, since tenants represent isolated units with their own users, data, and permissions. (1) Structure: • ​*Platform resources*​: Use a 
global
tenant where all users get 
reader
role • ​*Tenant-owned resources*​: Model tenants as parent tenants, clients as child tenants • ​*Role assignments*​: Assign users to multiple tenants with appropriate roles (2) The challenge: For tenant admins with ​_partial_​ client access, you'd need to explicitly assign them only to specific client tenants—not all clients under their tenant. *Option 2: ReBAC (Relationship-Based) * ReBAC handles your "tenant admin with access to only selected clients" requirement more elegantly through relationships. (3) However, you've identified the key tradeoff: ReBAC typically requires syncing resource instances to Permit to establish relationship tuples. ​*Minimizing Sync Overhead with ReBAC:*​ 1. ​*Sync only relationship-bearing resources*​: You don't need to sync every resource—only those that define ownership/access boundaries (tenants, clients) . Individual resources within a client can inherit permissions from their parent client relationship. 2. ​*Use ABAC for resource-level filtering*​: Combine ReBAC for structural relationships (platform→tenant→client) with ABAC attributes for filtering resources within those boundaries. This reduces what you sync. 3. ​*External data sources*​: OPAL supports fetching data from external APIs dynamically rather than syncing everything upfront. (4) ​*My Recommendation:*​ Given your requirement for tenant admins with selective client access, a hybrid approach works best: • Use ​*tenants*​ in Permit to represent your "clients" (the lowest isolation boundary) • Use ​*ReBAC*​ to model the platform→tenant→client hierarchy for role derivation • Sync only structural entities (tenants, clients) , not every resource within them I don't have complete documentation on avoiding all resource syncing while maintaining full ReBAC capabilities. Would you like me to connect you with the team for a deeper architecture discussion? Reach out via Email for a more detailed consultation on your specific architecture.
To learn more, see the sources I considered: [[1] Concepts / Glossary](https://docs.permit.io/overview/glossary) [[2] Implement Multi-Tenancy Role-Based Access Control (RBAC) in MongoDB](https://www.permit.io/blog/implement-multi-tenancy-rbac-in-mongodb) [[3] User Management Element](https://docs.permit.io/embeddable-uis/element/user-management) [[4] Best approach for handling large initial datasets in OPAL_DATA_CONFIG_SOURCES](https://github.com/permitio/opal/discussions/847)
s
Yes can you connect me @Ask Inkeep .
a
Thanks for tagging me @sarin regmi. I'll look through relevant sources and get back to you shortly.
Absolutely! For a deeper architecture discussion on your multi-tenant platform with the platform→tenant→client hierarchy and selective access requirements, please reach out to the Permit.io team directly via Email . They can help you work through: • The optimal modeling approach for your hierarchy • Minimizing sync overhead with ReBAC • Handling tenant admins with partial client access • Balancing tenant isolation with cross-tenant platform admin capabilities You can also join the Permit.io Slack community to discuss your architecture with the team and other developers facing similar challenges. (1)
To learn more, see the sources I considered: [[1] Best Practices for Multi-Tenant Authorization](https://www.permit.io/blog/best-practices-for-multi-tenant-authorization)
s
@Or Weis any guidance here.
o
You’re describing hierarchy here (tenants->clients) that always is a natural fir for ReBAC. There isn’t a wrong or right way, so the suggestions form the AI are valid too. My intuition - I’d model tenants as tenants and clients as groups (or resource instances) under the tenant. and maybe a tenant level resource instance all clients as nested under to apply derivations between tenant and clients. You can then do • RBAC checks on accessing tenant level objects without syncing specific instances • ReBAC checks on clients based on direct access or derived access from the tenant-top-level • ReBAC checks on client nested objects based on direct access or derived access from the tenant-top-level or client level
Can you share a little more about yourself / company and project - I can then potentially recommend more services to help with your journey here
👍 1
s
@Ask Inkeep lets say I have a resource called policy with id 123 within client A, who is member of tenant B, and lets say there is tenant C and cleint D as well, now if client D has a client admin who queries the policy endpoint with path param 123 for policy 123, how will ReBAC help here if the policy 123 is not synced to permit?
a
Thanks for tagging me @sarin regmi. I'll look through relevant sources and get back to you shortly.
p
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 ?
a
You've hit on the key limitation: ​*ReBAC requires the resource instance to be synced*​ to establish relationship tuples and evaluate permissions based on those relationships. (1) ​*If policy 123 isn't synced to Permit:*​ The PDP won't have a relationship tuple like 
policy:123#parent@client:A
to traverse. Without this, it can't determine that policy 123 belongs to Client A, which belongs to Tenant B—and therefore can't deny Client D's admin access based on relationship derivation. , (2) ​*Your options:*​ 1. ​*Sync resource instances at creation time*​ – When policy 123 is created under Client A, sync it to Permit and create the relationship tuple. This is the standard ReBAC approach. (3) 2. ​*Check at a higher level*​ – Instead of checking 
permit.check(user, "read", "policy:123")
, check against the client resource: 
permit.check(user, "read", "client:A")
. Your application then verifies that policy 123 belongs to Client A before serving it. The authorization boundary is the client, not individual policies. 3. ​*Use ABAC with attributes*​ – Store 
client_id
as an attribute on the policy in your database. Pass it as context during the check and use ABAC conditions to verify the user's client matches the policy's client. (4) ​*Practical hybrid approach:*​ • Sync only structural entities (tenants, clients) to Permit • For resources like policies, check permissions at the client level via ReBAC • Your application enforces that the requested resource belongs to the authorized client This avoids syncing every resource while maintaining access control boundaries.
To learn more, see the sources I considered: [[1] What is Relationship-Based Access Control (ReBAC)?](https://www.permit.io/blog/what-is-rebac) [[2] Role-Based Access Control (RBAC) VS. Relationship-Based Access Control (ReBAC)](https://www.permit.io/blog/rbac-vs-rebac) [[3] Fintech / Banking Demo Application](https://docs.permit.io/modeling/mesa-verde) [[4] Attribute-Based Access Control (ABAC) VS. Relationship-Based Access Control (ReBAC)](https://www.permit.io/blog/abac-vs-rebac)
s
@Ask Inkeep so you are saying we have to do a db lookup to fetch that item regardless
a
Thanks for tagging me @sarin regmi. I'll look through relevant sources and get back to you shortly.
Yes, if you're not syncing the individual resource instances (like policy 123) to Permit, you'll need to verify ownership in your application logic. ​*Here's how it works in practice:*​ 1. ​*Check permissions at the client level*​ – Use Permit to verify the user has access to the ​_client_​ (the
To learn more, see the sources I considered: [[1] Fintech / Banking Demo Application](https://docs.permit.io/modeling/mesa-verde)
e
Hi @sarin regmi , Thank you for reaching out. The AI answered your question or you need more help here?
s
@Eli Moshkovich mostly got answered 🙂
Open in Slack
PreviousNext
Powered by