Tenant-scoped RBAC
In Short
Tenant-scoped RBAC applies role-based access control inside a single customer boundary. Roles and permissions still follow the familiar user–role–permission model, but every grant is evaluated only within one tenant's data plane — a role in Tenant A cannot reach Tenant B's records even when the permission names look identical.
Definition
Standard RBAC answers which actions a role may perform. Tenant-scoped RBAC adds a mandatory scope: the tenant identifier that bounds every authorization decision. The model has four elements — users, roles, permissions, and tenant context — and the tenant context is not optional.
In practice, the same role name may exist in many tenants with different membership, but the permissions always apply to resources tagged with that tenant's identifier. Row-level security, partition keys, and application middleware each enforce the boundary; RBAC alone does not substitute for tenant isolation.
Designers still apply least privilege and separation of duties within the tenant. The characteristic failure mode is treating global roles as if they were tenant-local — for example, reusing a platform operator role definition inside a customer tenant without re-scoping grants, which collapses the boundary at review time.
Why It Matters
Multi-tenant SaaS evaluations ask two questions at once: who may act, and where they may act. Procurement and security reviewers expect both answers to be explicit. Tenant-scoped RBAC makes access reviews tractable per customer and prevents silent cross-tenant privilege bleed during onboarding or support workflows.
How QueryTek Uses It
QueryTek applies role-based access within the tenant boundary across Review, Tapestry, and platform services. Role definitions are designed for periodic review rather than one-off exceptions, and tenant context is enforced at the data layer as well as in application authorization. Specific role catalogues and permission matrices are shared through direct engagement.