RBAC Authorization Model: Mermaid Flowchart

RBAC Authorization Model flowchart diagram

About Source

Role-Based Access Control (RBAC) is the most widely deployed authorization model in enterprise applications. Rather than assigning permissions directly to individual users, RBAC introduces an intermediate abstraction — roles — which bundle related permissions together. Users are assigned roles, and roles carry permissions.

The core entities are users, roles, and permissions. A permission represents a specific action on a specific resource — for example, invoices:read, invoices:write, or users:delete. A role groups a coherent set of permissions that reflect a job function: an editor role might hold posts:read and posts:write; an admin role might hold those plus users:manage and settings:configure. A user is then assigned one or more roles.

When a request arrives, the authorization check follows a fixed pattern: look up the authenticated user's roles, expand each role to its set of permissions, check whether the required permission for the requested action is present in the union of all permissions. If yes, allow; if no, deny.

RBAC is operationally tractable because access changes are made at the role level, not per-user. Adding a new employee means assigning them a role; changing the access pattern of an entire team means updating a single role definition. This also makes auditing straightforward: the permission set for any role is explicit and enumerable.

RBAC's limitation is that it does not natively handle contextual or attribute-based decisions — for example, "users can only edit their own documents" or "this action is only allowed during business hours." For those requirements, see ABAC Authorization Model. The data structures that support RBAC are detailed in Role Hierarchy Structure, and the full runtime decision process is shown in Access Control Decision Flow.

Frequently asked questions

RBAC is an authorization model where permissions are grouped into roles, and users are assigned roles rather than individual permissions. An `admin` role might hold `users:manage` and `settings:configure`; an `editor` role might hold `posts:read` and `posts:write`. Users inherit all permissions of every role assigned to them.

When a request arrives, the system retrieves the authenticated user's roles, expands each role to its full set of permissions, and checks whether the required permission for the requested action is present in the union. If the permission is found, the request is allowed; otherwise it is denied. This check is typically performed in middleware before the request reaches business logic.

RBAC is operationally tractable at scale. Onboarding a new employee means assigning them a role, not configuring individual permissions. Changing what an entire team can do means updating a single role definition. Auditing is straightforward because the permission set of any role is explicit and enumerable. This makes compliance reporting significantly easier.

RBAC cannot natively express contextual or ownership-based rules — "users can edit their own posts but not others'", or "this action is only permitted during business hours". For these fine-grained, attribute-dependent decisions, ABAC (Attribute-Based Access Control) is more expressive. Many production systems use RBAC for coarse-grained role checks and add ABAC-style ownership rules on top.

The core schema has User, Role, and Permission tables with two many-to-many join tables: `user_roles` linking users to roles, and `role_permissions` linking roles to permissions. Role inheritance adds a `role_parents` self-referential table on Role. In multi-tenant systems, a Tenant foreign key scopes every entity so one tenant's roles cannot affect another's.

mermaid

flowchart LR
    U1([User: alice]) --> R1[Role: editor]
    U2([User: bob]) --> R1
    U3([User: carol]) --> R2[Role: admin]
    U3 --> R1

    R1 --> P1[Permission: posts:read]
    R1 --> P2[Permission: posts:write]
    R2 --> P1
    R2 --> P2
    R2 --> P3[Permission: users:manage]
    R2 --> P4[Permission: settings:configure]

    P1 --> RES1[(Resource: Blog Posts)]
    P2 --> RES1
    P3 --> RES2[(Resource: User Accounts)]
    P4 --> RES3[(Resource: App Settings)]