Why Permission Management Is Needed and How to Design RBAC Models

Why Permission Management Is Needed

In daily work developers constantly need to obtain various permissions—network access, code repository, monitoring platform, data query, etc.—and the lack of a systematic process can cause delays and security risks.

Why do we still need strict permission management despite the inconvenience?

For example, a payment company's operations backend can view all merchant, legal entity, transaction and rate configuration data; if every employee had unrestricted access, they could unintentionally modify rates, causing huge losses.

Another example is the confidentiality of merchant information; a malicious insider could sell this data to competitors, leading to severe consequences. Properly designed permission policies can prevent such violations.

Overall, permission management is a crucial guarantee for data security: different roles see different data, and operation limits vary accordingly.

How to let each role perform its duties in the system is the problem permission management solves.

2 Permission Model

2.1 Permission Design

From a business perspective, permissions can be classified as data‑view, data‑modify, etc. In system design this translates to page permissions, menu permissions, button permissions, and hierarchical menus (first‑level, second‑level, third‑level). Designing permissions as a tree structure makes the request process clear.

As shown below:

According to this architecture, a button’s parent is a second‑level menu, whose parent is a first‑level menu, making permission requests transparent.

2.2 Why Roles

After clarifying the permission structure, we need to decide how to assign permissions to users. Direct user‑permission assignment becomes cumbersome as the number of users grows.

This simple user‑permission model quickly becomes unmaintainable. Many users share the same set of permissions, so a mediating entity—**role**—can be introduced. This is the classic Role‑Based Access Control (RBAC) model.

2.3 Evolution of Permission Models

2.3.1 RBAC Model

With roles, permissions are assigned to roles, and users are assigned to roles. A permission can belong to multiple roles, a role can have multiple permissions, and a user can have multiple roles.

This classic RBAC model reduces the maintenance cost dramatically, especially for large organizations where a few hundred roles can cover thousands of users.

However, real‑world businesses often require hierarchical permissions (e.g., higher‑level positions inherit lower‑level permissions), leading to the need for role inheritance.

2.3.2 Role‑Inheritance RBAC Model

Also known as RBAC1, this model allows a higher‑level role to inherit all permissions of a lower‑level role while adding extra permissions. For instance, a finance director inherits the permissions of a finance manager, who inherits those of a cashier.

The inheritance can be a tree (single parent) or a directed acyclic graph (multiple parents). Both structures are illustrated below.

2.3.3 Constrained RBAC Model

Also called RBAC2, this model adds constraints for security, such as mutually exclusive roles, cardinality limits, and prerequisite conditions.

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

Role mutual exclusion: If Role A and Role B are mutually exclusive, a user cannot hold both simultaneously.

For example, a user assigned the “accountant” role cannot also hold the “auditor” role; one must be removed before the other is granted.

Cardinality constraints: Limit the number of users that can be assigned a particular role (e.g., only one super‑admin) or limit how many roles a user may have.

Prerequisite constraints: To obtain a higher‑level role, a user must first hold the lower‑level role (e.g., a technical lead must first be a regular developer).

2.4 User Segmentation

2.4.1 User Groups

When many users share the same set of permissions, creating a user group and assigning a role to the group simplifies management.

In short, a user group is a collection of users, while a role is the bridge between users and permissions.

2.4.2 Organization

Companies have organizational structures; assigning roles by organization enables automatic permission allocation when users join or change departments.

Data permission can also be controlled by linking roles to organizations, ensuring users only see data belonging to their own org.

2.4.3 Position

Positions (e.g., finance director, finance manager, accountant) have distinct permission needs; roles can be linked to positions, often in a many‑to‑many relationship.

2.5 Ideal RBAC Model

The ideal model aggregates RBAC, RBAC1, RBAC2, user groups, organizations, and positions to handle large data volumes and complex business scenarios.

For small teams (under ten people) a simple user‑permission model may suffice; for larger enterprises the ideal RBAC model provides scalability and security.

3 Permission System Table Design

3.1 Standard RBAC Table Design

The standard RBAC schema consists of six tables: user, role, permission, user‑role relation, role‑permission relation, and an optional permission hierarchy. The core relationship is represented by 用户-角色-权限 .

3.2 Ideal RBAC Table Design

The ideal RBAC schema extends the standard model with additional tables for role inheritance, constraints, user groups, organizations, and position mappings, resulting in a more complex ER diagram.

4 Conclusion

The article provides a comprehensive, step‑by‑step introduction to permission model design, emphasizing that the choice of model should be based on company size, business complexity, and personnel count. Simpler RBAC works for small teams, while the ideal model addresses large‑scale, complex scenarios.