Designing Permission Management and RBAC Models: From Basic Needs to Ideal Architectures

In daily development work, engineers constantly request various permissions—network access, code repository, monitoring tools, and data queries—making permission management a critical part of data security and operational efficiency.

The article first explains why strict permission control is necessary, using examples from payment platforms where unrestricted access to merchant, transaction, and fee‑rate data could lead to severe financial loss or data leakage.

1. Why Permission Management Is Needed

Permissions ensure that only authorized roles can view or modify sensitive information, protecting both the company and its customers.

2. Permission Model

2.1 Permission Design – Permissions can be categorized as view or edit rights, which map to page, menu, and button permissions in a system. A tree‑structured design (menu → submenu → button) makes permission requests clear.

2.2 Why Roles Are Required – Directly assigning permissions to each user becomes unmanageable as the user base grows. Introducing a role as an intermediary (user‑role‑permission) simplifies administration.

2.3 Evolution of Permission Models

2.3.1 RBAC Model – Users are linked to roles, and roles to permissions, forming a many‑to‑many relationship.

2.3.2 Role‑Inheritance RBAC (RBAC1) – Higher‑level roles inherit all permissions of lower‑level roles, allowing hierarchical structures such as finance director > finance manager > accountant.

2.3.3 Constrained RBAC (RBAC2) – Adds constraints like role mutual exclusion, cardinality limits, and prerequisite conditions to enforce business rules.

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

2.4 User Segmentation

2.4.1 User Groups – Group users with similar permission needs and assign roles to the group, reducing repetitive assignments.

2.4.2 Organization – Align roles with organizational hierarchy so that new hires automatically inherit the correct permissions, and transfers require only organization changes.

2.4.3 Position – Map specific job positions (e.g., finance director, accountant) to appropriate roles, often a one‑to‑one user‑position relationship.

3. Permission System Table Design

3.1 Standard RBAC Table Design – Requires six tables: users, roles, permissions, user‑role mapping, role‑permission mapping, and optionally role‑permission constraints. The relationship is expressed as 用户-角色-权限 .

3.2 Ideal RBAC Table Design – Extends the standard model to include role inheritance, constraints, user groups, organizations, and positions, resulting in a more complex ER diagram that can handle large‑scale, multi‑tenant systems.

4. Conclusion

The article emphasizes that the choice of permission model should match company size, business complexity, and user count; for most companies under a thousand employees, a classic RBAC model is sufficient, while larger organizations may benefit from the ideal, extensible RBAC architecture.