Mastering Role‑Based Access Control: Build a Simple Permission System

Author Xiao Xinyu, a front‑end engineer at WeDoctor Cloud Services, shares his insights on designing a simple permission system.

Permission systems are needed whenever different users require different functionalities on the same platform, such as video‑on‑demand services or admin back‑ends.

What Is the RBAC Model

RBAC (Role‑Based Access Control) assigns permissions to roles, and users acquire permissions by being assigned to appropriate roles, simplifying management through hierarchical relationships.

Roles act as an intermediary between users and permissions, making large‑scale permission management more efficient.

Roles are preferred over direct user‑permission bindings because they reduce redundancy and simplify updates in systems with many users sharing the same permission sets.

RBAC Model Classifications

Four levels exist: RBAC0, RBAC1, RBAC2, and RBAC3. RBAC0 is the basic model; the others extend it.

2.1 RBAC0

The simplest model, which can be implemented in two ways:

One‑to‑many: each user has a single role, but a role can have many users.

Many‑to‑many: users can hold multiple roles, and each role can be assigned to many users.

2.2 RBAC1

Introduces role hierarchies, allowing child roles to inherit all permissions of their parent roles.

2.3 RBAC2

Role separation: mutually exclusive roles cannot be assigned to the same user.

Cardinality constraints: limit the number of users that can be assigned a particular role.

Prerequisite roles: higher‑level permissions require possession of lower‑level roles.

Runtime separation: a user may hold multiple roles but can activate only one at a time.

2.4 RBAC3

The most comprehensive model, combining RBAC0‑RBAC2 features and adding full role inheritance and separation of duties.

Key Characteristics of RBAC

Facilitates authorization management through role hierarchies.

Supports the principle of least privilege by assigning only necessary permissions to each role.

Enables separation of duties, preventing a single role from performing conflicting tasks.

Lacks built‑in support for enforcing operation order, which can be a limitation for certain workflows.

Designing a Permission System

A simple RBAC‑based system should include three core entities: users, roles, and permissions.

Define permissions (e.g., pages, buttons, APIs), define roles that aggregate relevant permissions, and create users who are assigned to roles.

Link them by creating a role, assigning permissions to that role, and then assigning the role to users. The workflow is illustrated below.

Mapping this flow to a hospital system: doctors see only doctor‑specific pages, nurses see appointment registration, while administrators have full access.

Thus, by connecting users, roles, and permissions, a functional and maintainable permission system is achieved.

This article summarizes the author's experience building a permission system, introducing RBAC concepts and providing guidance for designing role‑based access control.