Multi-Tenancy & Delegation

Multi-Tenancy & Delegation

Keycloak was just the beginning. Meet Keymate.

Estimated read: 10–12 minutes

TL;DR

Roles tell who. Tenants and scopes tell where—and how far.

At enterprise scale, RBAC alone cannot express tenant isolation, organizational hierarchy, or safe delegation. On modern IAM platforms, this often leads to role explosion, manual workarounds, and accidental overreach.

The fix is not replacing your IAM. Instead, treat **tenants, org trees, and scopes as first-class authorization context **, layer them on top of RBAC, and adopt safely through parallel run.

---

When tenant boundaries are implicit, mistakes are inevitable

Without first-class tenants and scopes, every admin is one mistake away from becoming global.

In many IAM deployments, tenant separation lives in documentation, naming conventions, or spreadsheets—not in the authorization model itself. Admins manually select the “right” realm, client, or tenant. One slip, and production data crosses boundaries.

Multi-tenancy cannot be a convention. It must be enforced.

---

Tenants, org trees, and scopes are not roles

Encoding tenant or organizational structure into role names guarantees sprawl and confusion.

To model real-world boundaries, three primitives must exist outside roles:

• Tenant — the hard boundary for data and administration
• Org tree — a hierarchical structure (for example: /ACME/EMEA/Finance)
• Scope — how far authority extends within that structure
  (authorization scope, not OAuth2 client scopes)

Roles answer who. These primitives answer where and how far.

---

From scoped access to delegated authority

Once access is scoped correctly, the next question becomes inevitable:

Who is allowed to manage that scope?

In multi-tenant systems, delegation is often treated as copying roles or redistributing power. In practice, this is where many platforms accidentally introduce global authority through convenience.

Delegation should do the opposite.

---

Delegated administration without global access

Delegation should always reduce authority—not redistribute it.

Common delegated administration patterns include:

• Tenant admin — full control within a single tenant
• Org admin — control limited to an org subtree
• Resource admin — control over specific resource groups

Global authority is intentionally excluded. It cannot—and should not—be delegated.

Instead of cloning roles per tenant, delegate by scoping authority, not identity.

---

Why RBAC breaks down in multi-tenant systems

Role-based delegation scales linearly. Real-world organizations scale hierarchically.

RBAC-only systems accumulate roles like:

• admin_acme
• admin_acme_us
• admin_acme_us_sales
• admin_acme_us_sales_rw

This is not access control—it is encoded metadata.

❌ admin_acme_us_sales_rw
✅ role=ADMIN + scope=/ACME/US/Sales

Scopes collapse this explosion into stable, reviewable rules.

---

Developer view: small, clear, enforceable rules

For developers, the goal is simple: make authorization explicit, minimal, and observable.

The rule below is evaluated by Keymate’s centralized policy engine, not hard-coded into application logic. Applications remain policy-agnostic.

allow('manage_user') if
  user.role == 'ADMIN' &&
  user.tenantId == target.tenantId &&
  startsWith(target.orgPath, user.scope.orgPath)

This logic is enforced alongside your existing IAM and integrated through standard interfaces—without rewriting application code or embedding policy into tokens.

Decision traces then explain why access was granted or denied—no folklore, no guesswork.

{
  "decision": "allow",
  "tenant": "ACME",
  "scope": "/EMEA",
  "policy": "DelegatedOrgAdmin"
}

---

Migration without fear: tenant-aware parallel run

Parallel run builds confidence—compare decisions, then cut over.

Think of parallel run as a shadow authorization lane. It never blocks traffic. It only explains what would have happened under tenant-aware policies.

Run legacy IAM checks and new policies side-by-side. Capture mismatches. Fix intent. Cut over gradually.

---

What we are (and are not) saying

• ✔ Keep your existing IAM as the identity backbone

• ✔ Add tenant, org, and authorization scope context

• ✔ Delegate safely and visibly

• ✖ Not a rip-and-replace IAM project

• ✖ Not global admins everywhere

---

Where this series goes next

Part 4 — Policy Lifecycle & Explainability
Why authorization policies should be treated like code: diff, review, simulate, approve, and roll back.

Series navigation
← Why Keymate?
← The Limits of RBAC
→ Policy Lifecycle & Explainability (coming next)