Designing Scalable Permission Systems: From Basic RBAC to Advanced Role Hierarchies

Why Permission Management Is Needed

Developers frequently need access to network resources, code repositories, monitoring platforms, and data query tools. Without a structured permission system, ad‑hoc requests become time‑consuming and critical data access may be blocked by lengthy approval processes. In a payment‑company backend, unrestricted access to merchant, legal, transaction, and rate‑configuration data could lead to accidental financial loss or data leakage. Permission management therefore enforces data security by ensuring that different roles see only the data they are authorized to view and can perform only permitted operations.

Permission Model

Permission Design

Permissions are classified by business actions such as view and edit , which map to page, menu, and button permissions in the UI. Menus often form a hierarchical tree (e.g., one‑level, two‑level, or three‑level menus). Designing permissions as a tree makes the request process transparent: a button belongs to a second‑level menu, which in turn belongs to a first‑level menu.

Roles

When the permission hierarchy is clear, the next step is assigning permissions to users. Direct user‑permission assignment creates a many‑to‑many matrix that quickly becomes unmanageable as the user count grows. Introducing a third entity— role —allows grouping of common permissions, turning the matrix into two many‑to‑many relationships (user‑role and role‑permission) and dramatically reducing administrative effort.

Evolution of Permission Models

RBAC Model

The classic Role‑Based Access Control (RBAC) model connects users, roles, and permissions: a role can have multiple permissions, a user can be assigned multiple roles, and a role can be linked to many users. This three‑entity schema scales well; a company with tens of thousands of employees can be covered by a few hundred roles.

Role‑Inheritance RBAC (RBAC1)

RBAC1 adds hierarchical role inheritance. An upper‑level role inherits all permissions of its lower‑level role(s) and may have additional exclusive permissions. Two inheritance structures are common:

Tree‑shaped: each lower role has a single parent, while a parent can have multiple children.

Directed acyclic graph (DAG): a role may inherit from multiple parents, and a parent may have multiple children.

Constrained RBAC (RBAC2)

Real‑world security policies often impose additional constraints:

Common constraints include role mutual exclusion, cardinality limits, and prerequisite relationships.

Role mutual exclusion: Mutually exclusive roles cannot be assigned to the same user simultaneously (e.g., a user cannot be both “Accountant” and “Auditor”).

Cardinality constraint: Limits the number of users that may hold a particular role (e.g., only one super‑admin) or the number of roles a user may have.

Prerequisite constraint: A user must possess a lower‑level role before being granted a higher‑level role (e.g., “Tech Lead” requires the “Developer” role).

User Segmentation

User Groups

When many users share identical permission needs, a user group aggregates them. Assigning a role to a group automatically grants that role to all its members, simplifying bulk permission management.

Organization‑Based Assignment

Permissions can be aligned with the company’s organizational hierarchy. Members of the same department typically need similar permissions, so linking roles to organizations enables automatic permission assignment when users join or move between departments. This also restricts data visibility to the organization’s own data.

Position‑Based Assignment

Within an organization, different positions (e.g., finance director, supervisor, cashier) require distinct permission sets. Positions are typically a one‑to‑one mapping to users, while a position can be linked to multiple roles.

Ideal RBAC Model

The ideal model integrates standard RBAC, role inheritance, constraints, user groups, organization‑based assignment, and position‑based assignment into a unified schema capable of handling large data volumes and complex business rules. Small teams (<10 people) may use a simple user‑permission table; larger enterprises benefit from the full model for scalability and maintainability.

Permission System Table Design

Standard RBAC Table Design

To represent the user‑role‑permission relationships, create three core tables ( User , Role , Permission ) and two junction tables ( User_Role , Role_Permission ). This six‑table schema captures the many‑to‑many relationships.

用户-角色-权限

Extended (Ideal) RBAC Table Design

The ideal schema extends the standard model with additional tables for role constraints, user groups, organizations, and positions, resulting in a more complex ER diagram. The role‑mutual‑exclusion table can be attached to either roles or permissions depending on business needs.