RBACRole-Based Access Control

NIST defines RBAC in four levels:

• Core RBAC (RBAC0) — users, roles, permissions; user-role assignment; role-permission assignment; sessions.
• Hierarchical RBAC (RBAC1) — roles inherit permissions from parent roles (Supervisor inherits Operator).
• Constrained RBAC (RBAC2) — static and dynamic separation of duties (e.g. the user who prepared a batch cannot also approve it).
• Symmetric / Combined RBAC (RBAC3) — both hierarchies and constraints.

• RBAC — permissions via role membership. Predictable, auditable, well-understood by auditors.
• ABAC (NIST SP 800-162) — permissions evaluated dynamically against attributes of the user, resource, action and environment (e.g. allow read only if shift = day and site = US-1). Powerful but harder to audit; favoured by cloud-native authorisation engines (OPA, Cedar).
• ReBAC (relationship-based, popularised by Google Zanzibar / SpiceDB / OpenFGA) — permissions derived from relationships in a graph (this user is the supervisor of the operator who owns this batch).

Most regulated-manufacturing systems run RBAC at the policy layer with ABAC-style attributes (site, shift, training valid until, MFA recency) added as guards. Pure ABAC is rare because auditors prefer the deterministic role-to-permission grid.

SoD is the core constraint that makes RBAC regulated-grade. Two kinds:

• Static SoD — a user cannot hold two mutually exclusive roles simultaneously (e.g. Preparer + Independent Reviewer for recipe approval).
• Dynamic SoD — a user can hold two roles but cannot exercise both on the same record (e.g. the operator who logged a dispense step cannot also be the two-person reviewer of that same step).

Both 21 CFR 211.186 (recipe approval — two e-sigs, preparer + independent reviewer) and 21 CFR 211.188 (batch record review by Quality Unit) rely on SoD. In V5 the constraint is enforced server-side, not just in the UI — a manually crafted API call from the preparer cannot bypass it.

Two related principles every RBAC design should honour:

• Least privilege — grant the minimum permissions required to perform the role's function. An operator role grants kiosk access, not admin UI access.
• Minimum necessary (HIPAA term, applies more broadly) — when the role does have data access, the system surfaces only the records the user needs (this operator's work orders, this site's recipes, not the global tenant view).

RBAC lives or dies on lifecycle:

• Joiner — onboarding triggers role assignment, mandatory training, kiosk enrolment; access starts only after the training-record system flags competence as current.
• Mover — promotion / lateral move triggers role removal + new role assignment + new training prerequisites; no role accumulation.
• Leaver — termination triggers immediate role removal across all roles. SCIM from the IdP closes this loop within seconds; manual offboarding is the most common audit observation.

ISO 13485 §6.2 + ICH Q10 + 21 CFR 211.25 require personnel to have the education, training and experience to perform their assigned functions. The practical implementation is to gate role activation on a valid, current training record:

• Operator cannot start a task if assigned required SOPs are overdue or unacknowledged on the current effective version (V5 enforces this as a hard kiosk block).
• Releaser cannot sign a batch if the batch-release SOP version they trained on is not the currently effective version.
• Independent Reviewer must hold a competence record distinct from Preparer.

V5 ships a small, opinionated default role catalogue; tenants can extend within the same SoD constraints:

• Owner — billing + workspace lifecycle; cannot perform GxP actions without a separate operational role.
• Quality Manager — recipe approval, batch release, deviation / CAPA sign-off, training assignment, document control.
• Production Supervisor — work-order release, line clearance, operator scheduling, deviation triage.
• Operator — kiosk-only; clock-in, dispense weighing, in-process checks; locked to /app/kiosk.
• Maintenance / Engineering — asset records, calibration scheduling, change-control proposals.
• Auditor (read-only) — full read across batch records, audit trail, validation pack; no write.
• Controller — labor / overhead rates, COGS roll-up; no GxP actions.
• Platform Admin — Lovable-internal allowlisted accounts only; not exposed to tenants.

• Granting permissions directly to users — auditors and reviewers cannot reason about access.
• Single "admin" mega-role that violates SoD by definition.
• SoD enforced in UI only, bypassable via API.
• No training-gate on role activation; operators run on expired SOP versions.
• Leavers not removed promptly; old credentials remain valid for weeks.
• Role hierarchy lets a Supervisor implicitly inherit Independent Reviewer rights — Static SoD violation.
• Owner role used as everyday operational role — blast radius too large.
• Role definitions drift between tenants without a documented role catalogue + change-control trail.