How do you design RBAC vs ABAC vs ReBAC for multi‑tenant SaaS?

Access control is one of those topics that looks simple on a whiteboard but quietly makes or breaks a real multi tenant SaaS. RBAC, ABAC, and ReBAC are three common models for authorization. In practice you rarely choose only one. You usually combine them into a layered design that keeps tenants isolated, policies expressive, and performance predictable.

For a system design interview, being able to explain how you would combine role based, attribute based, and relationship based access control in a multi tenant SaaS will instantly signal senior level thinking. This guide walks through that design in a structured, implementation friendly way.

Why it Matters for Multi Tenant SaaS

In a multi tenant SaaS, you are not just answering the question “Can this user access this resource”. You are really answering a richer question.

• Is this user part of the correct tenant
• Do tenant admins control their own roles and permissions
• Can teams define fine grained sharing rules without involving your support team
• Can you evolve policies without rewriting all your services
• Does the system remain fast and safe at scale across many tenants

Getting RBAC vs ABAC vs ReBAC right gives you a clean separation of concerns.

• RBAC handles “who plays what role inside which tenant”
• ABAC handles “under what conditions and attributes does access make sense”
• ReBAC handles “who is related to this resource through groups, projects, ownership, sharing and similar links”

Interviewers love this topic because it mixes conceptual design, data modeling, and performance trade offs in distributed systems.

How it Works Step by Step

Think of the design in six steps:

Step 1. Define your core entities

At minimum you need these entities in a multi tenant SaaS authorization model.

1. Tenant
2. User
3. Resource
4. Role
5. Permission or action
6. Relationship

You will typically have tables or collections similar to

• Tenants
• Users with tenant membership
• Roles per tenant
• Role to permission mapping
• Resource records that belong to tenants
• Relationship edges user resource or group resource

These give you a neutral foundation that works with RBAC, ABAC, and ReBAC.

Step 2. Start with RBAC as the backbone

RBAC is usually your base layer for multi tenant SaaS because it maps well to the mental model of customers.

• Each tenant can define roles like Owner, Admin, Manager, Viewer
• Each role has a set of permissions such as read document, edit document, invite user, configure billing
• Users are assigned roles within a tenant

The core check becomes

User has role R in tenant T Role R grants permission P on resource type X Resource belongs to tenant T

This already gives you tenant isolation and clear admin controls. Many SaaS products can get quite far with RBAC alone.

Step 3. Add ABAC for contextual policies

ABAC extends RBAC with attributes about the user, resource, action, or environment. Typical examples in multi tenant SaaS.

• User attributes department, location, clearance level
• Resource attributes confidentiality level, owner team, region, status
• Context attributes request time, device trust level, network zone

You model policies that say things like

• Managers can approve expenses up to amount limit that depends on their department budget
• Only users in region X can access data stored in region X to satisfy data residency
• Support staff can view tenant configuration only when using a trusted device policy attribute

Implementation wise you can

• Store attributes in user and resource tables
• Evaluate policies in a dedicated policy engine or service
• Compose RBAC decision and ABAC decision with a logical AND

Final decision looks like

Access granted if RBAC says allowed And ABAC policies evaluate to true

Step 4. Add ReBAC for sharing and collaboration

ReBAC focuses on relationships. In multi tenant collaboration products you often want semantics such as

• User is a member of group which is assigned to project which owns the document
• User is a collaborator on this item
• User follows a page or is in a channel where the resource was shared

You model this as a graph of relationships.

• Nodes. users, groups, teams, resources
• Edges. member of, owner of, shared with, parent of, child of

A ReBAC engine answers questions like:

• Is user U related to resource R through any allowed path in the graph

For multi tenant SaaS, you normally keep relationship graphs tenant scoped or partitioned by tenant. That way you keep data and traversal bounded within each tenant and avoid cross tenant leakage.

You can implement ReBAC with

• A graph store
• A specialized authorization engine similar to Zanzibar style designs
• Precomputed relationship tables when requirements are simple

Step 5. Combine RBAC, ABAC, and ReBAC into a unified check

During a request, your authorization service can run in this order.

1. Authenticate user and identify tenant

2. Resolve user roles in that tenant RBAC

3. Resolve relationships between user and resource ReBAC

4. Fetch attributes for user, resource, and context ABAC

5. Evaluate policies

   • Tenant isolation. user tenant must match resource tenant unless global admin
   • RBAC. user role must grant required permission
   • ReBAC. if resource is shared through a relationship, treat it as alternative path
   • ABAC. contextual constraints must pass

6. Cache decision or intermediate data where useful

Composition strategy can be:

• Deny if tenant isolation fails
• Allow if RBAC or ReBAC says allowed and ABAC constraints are satisfied

This gives you flexible sharing while keeping strong tenant boundaries.

Step 6. Data modeling for multi tenant

For multi tenant SaaS you want both safety and performance. Typical modeling patterns.

• Every resource has a tenant id column or field
• All role and relationship tables include tenant id
• Index tenant id first to make queries always scoped to one tenant
• Optionally partition data by tenant in your storage layer when scale grows large

This design ensures that even if you make a mistake in application logic, it is still hard to accidentally cross tenant boundaries at the data layer.

Real world example multi tenant collaboration suite

Consider a SaaS product similar to Notion or Confluence. Tenants are companies. Users collaborate on pages and documents within workspaces and projects.

Possible design:

• RBAC

  • Roles inside each tenant. Owner, Workspace admin, Project admin, Editor, Viewer
  • Roles map to permissions like create page, delete page, manage users

• ABAC

  • User attributes. department, employment type, country

  • Resource attributes. confidentiality tag internal, restricted, secret

  • Policies

    • Contractors cannot access secret documents
    • Only users in the Legal department can access documents tagged legal restricted

• ReBAC

  • Users join groups or workspaces
  • Workspaces contain projects and pages
  • Sharing model. you can share a page with specific users, groups, or entire workspace

Access check flow for “User wants to read page P”.

1. Check that user belongs to the same tenant as page P
2. Check RBAC. does user have a role that includes read page in this workspace
3. Check ReBAC. is user a direct collaborator on page P or member of a group that has been shared access
4. Evaluate ABAC policies. does user location and employment type allow this confidentiality level

If all checks pass, the user sees the page. Otherwise you return an authorization error.

This pattern scales from small startups to large enterprise multi tenant deployments and fits nicely in a system design interview scenario.

Common pitfalls and trade offs

Some pitfalls appear repeatedly in both production systems and interviews.

• Mixing tenant isolation with global roles in an ad hoc way. Global admins are useful but you must model them explicitly with clear scope and audit
• Using only RBAC and then letting roles explode. Every exception becomes a new role and you end up with hundreds of roles per tenant. This is a signal that you actually need ABAC or ReBAC
• Encoding complicated business rules directly in code in many services instead of using a central authorization service
• Storing relationships in a way that makes graph queries very slow at scale. for example naive join chains across large tables without indexing
• Overusing ABAC with extremely dynamic policies. This can make reasoning, debugging, and caching difficult

Trade offs among the three models:

• RBAC is simple and great for most admin workflows but limited for complex sharing
• ABAC is powerful and flexible but harder to explain to customers and engineers
• ReBAC models real collaboration naturally but requires careful data modeling and sometimes a specialized engine

In interviews, it is fine to propose starting with RBAC plus simple attributes, then explain how you would evolve to fuller ABAC and ReBAC as requirements become more advanced.

Interview Tip

A common system design interview question is.

“Design an authorization service for a multi tenant document editing platform. How would you model roles, permissions, and sharing, and how would you keep tenants isolated.”

A strong answer:

• Starts with RBAC per tenant as the base
• Adds ABAC for compliance and contextual rules
• Adds ReBAC for document sharing and group based collaboration
• Mentions tenant id at every layer of the data model
• Mentions caching of permission checks and denormalized relationship tables for hot paths

If you can sketch entities and access check flow clearly, you stand out as someone who can design scalable architecture, not just individual microservices.

Key Takeaways

• Use RBAC as the backbone for multi tenant SaaS, mapping user roles to permissions inside each tenant
• Add ABAC when you need contextual policies such as region, confidentiality level, or device trust
• Add ReBAC when your product needs flexible sharing and collaboration based on relationships
• Always model tenant id explicitly on users, resources, roles, and relationships to enforce isolation
• In a system design interview, explain how you will evolve from simple RBAC to a layered RBAC plus ABAC plus ReBAC model as complexity grows

Comparison table RBAC vs ABAC vs ReBAC

FAQs

Q1. What is RBAC in multi tenant SaaS?

RBAC in multi tenant SaaS means each tenant defines roles such as Admin, Manager, or Viewer and maps those roles to permissions. Users are granted roles within a tenant, and all resources are tagged with tenant id. Authorization checks verify both tenant match and role based permission.

Q2. When should I choose ABAC instead of pure RBAC?

Choose ABAC when rules depend on attributes rather than just roles. For example, allowing only employees in a certain region to access data, or limiting access for contractors. If you notice role explosion or many exceptions encoded in code, ABAC is usually the right next step.

Q3. How does ReBAC help in collaboration features?

ReBAC models collaboration as a graph of relationships. User member of group. Group has access to project. Project owns resource. The authorization system can walk these relationships to decide access. This matches natural concepts like teams, channels, and shared documents far better than roles alone.

Q4. Can I mix RBAC, ABAC, and ReBAC in one authorization system?

Yes. In fact, most mature SaaS products do exactly that. RBAC provides the base permission model, ABAC enforces contextual policies, and ReBAC enables sharing and group based collaboration. The key is to define a clear evaluation order and keep tenant isolation checks at the top.

Q5. How do I enforce tenant isolation with these models?

Always tag users, roles, relationships, and resources with tenant id. Scope all queries for roles, attributes, and relationships by tenant id. Deny any access where user tenant and resource tenant do not match, except for carefully controlled global admin roles with strong auditing.

Q6. What datastore should I use for authorization policies?

Common patterns are a relational database for RBAC data, a policy store or configuration service for ABAC rules, and either relational tables or a graph data store for ReBAC edges. In a system design interview, explain your reasoning around consistency, latency, and caching rather than focusing only on one product.

Further Learning

If you want a deeper foundations first understanding of access control, tenancy models, and core building blocks for distributed systems, explore the course Grokking System Design Fundamentals which walks through real SaaS examples and data modeling patterns.

For more advanced authorization topics that appear in complex system design interview questions, including multi tenant architectures, caching strategies, and global scale design, check out Grokking the System Design Interview where you can practice end to end designs that integrate RBAC, ABAC, and ReBAC in realistic scenarios.

• Grokking System Design Fundamentals
• Grokking the System Design Interview