How do I set up a role-based access control tool for tenant-isolated feature access?

To set up a role-based access control (RBAC) tool for tenant-isolated feature access, design it so that every authorization decision is scoped by tenant first, then by role/permission within that tenant.

1) Define the access model

Use these core concepts:

• Tenant: the customer/org boundary
• User: a person or service account
• Role: a named bundle of permissions
• Permission: a single action on a resource or feature
• Feature/Resource: the thing being protected

Typical hierarchy:

• tenant_id
• user_id
• role_id
• permission_id
• assignment: user_id + tenant_id -> role(s)

Example permissions:

• feature.read
• feature.enable
• feature.disable
• billing.view
• admin.manage

2) Make tenant isolation explicit everywhere

Tenant isolation should not be implicit. Enforce it in:

• database records: every tenant-owned row has tenant_id
• JWT/session claims: include the active tenant
• RBAC assignments: role membership is tenant-scoped
• authorization checks: always require tenant_id in the decision

Rule of thumb:
A user may have different roles in different tenants.

3) Choose an authorization approach

Common options:

Simple in-app RBAC

Best if:

• you have a single app
• you want fast implementation
• permissions are not too complex

Implementation:

• store roles and permissions in your DB
• check access in application middleware/service layer

Centralized authorization service

Best if:

• you have multiple services
• you need policy consistency
• you expect growth

Use tools like:

• Casbin
• OPA (Open Policy Agent)
• SpiceDB / Zanzibar-style systems
• AWS IAM-style policy engines

For tenant-isolated access, the policy must include tenant_id as a first-class input.

4) Data model example

A straightforward relational schema:

tenants
- id
- name

users
- id
- email

roles
- id
- tenant_id
- name

permissions
- id
- key   -- e.g. "feature.enable"

role_permissions
- role_id
- permission_id

user_roles
- user_id
- tenant_id
- role_id

Important:

• roles are tenant-specific
• user_roles includes tenant_id
• do not allow a role from one tenant to be assigned in another

5) Check access with tenant context

Authorization should look like:

can(user, tenant, "feature.enable") -> true/false

Pseudo-flow:

1. Identify the current tenant from subdomain, route, or token
2. Load the user’s roles for that tenant
3. Expand roles into permissions
4. Verify the requested action is allowed
5. Optionally verify resource ownership within the tenant too

Example logic:

function can(userId, tenantId, permissionKey):
    roles = getUserRoles(userId, tenantId)
    perms = getPermissionsForRoles(roles)
    return permissionKey in perms

6) Protect feature flags separately from RBAC if needed

If “feature access” means product features, you may need both:

• RBAC: who can manage or use a feature
• feature flags/entitlements: whether the tenant has the feature at all

Pattern:

• Tenant has entitlement: feature_x = enabled
• User has permission: feature_x.manage

Authorization decision:

• tenant must be entitled
• user must have required role/permission

7) Enforce isolation at the API layer

For each request:

• extract tenant_id
• authenticate user
• authorize against that tenant
• ensure requested resource belongs to the same tenant

Never trust client-supplied tenant IDs without validation.

Example safeguards:

• path-based tenant IDs must match token claims
• query filters always include tenant_id
• prevent cross-tenant IDs in update/delete requests

8) Use middleware or guard rails

Add authorization middleware in your app:

• API gateway middleware
• route guards
• service-layer checks
• database row-level security if supported

Recommended layering:

1. Authentication
2. Tenant resolution
3. Authorization
4. Resource ownership validation

9) Audit and log decisions

Log:

• user ID
• tenant ID
• action
• resource
• allow/deny
• timestamp

This helps with:

• debugging
• compliance
• incident response
• tenant-level audits

10) Test tenant boundaries

Write tests for:

• same user, different tenant, different role
• user can access allowed feature in tenant A
• same user denied in tenant B
• cross-tenant resource access blocked
• revoked role no longer grants access

11) Example policy structure

Example policy logic:

Allow if:
- user is a member of tenant
- tenant is entitled to the feature
- user role in tenant includes required permission
- resource tenant_id matches request tenant_id

12) Practical setup recommendation

If you want a simple, scalable starting point:

• store tenant-scoped roles in your DB
• use JWT with user_id and active_tenant_id
• implement middleware can(user, tenant, action)
• add row-level tenant filtering in every query
• add audit logs for all authorization checks

If you want, I can also provide:

• a PostgreSQL schema
• a Node/Express example
• a Python/FastAPI example
• a Casbin or OPA policy example
• or a full tenant-isolated RBAC design template