Designing Scalable Permission Systems: From Basic RBAC to Advanced Models

1 Why Permission Management Is Needed

In daily work developers constantly need various permissions such as network access, code repository, monitoring platform, and data query, and the lack of proper permissions can cause security risks and operational delays.

For example, a payment company's operations backend contains merchant, legal entity, transaction, and rate configuration data; unrestricted access could allow anyone to modify rates, leading to huge losses, while leaking confidential merchant data could harm competitors.

Therefore, permission management guarantees data security by ensuring different roles see and operate only the data relevant to their responsibilities.

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

2 Permission Model

2.1 Permission Design

Permissions can be classified by business type into data view, data modification, etc., corresponding to page, menu, and button permissions in the system. Menus are hierarchical (first‑level, second‑level, third‑level). Designing permissions as a tree structure makes requests clear.

Example diagram:

Buttons are children of second‑level menus, which are children of first‑level menus, providing a clear view of required permissions.

2.2 Why Roles

When users are many, assigning permissions individually becomes inefficient. Introducing roles as an intermediate entity allows multiple users to share the same set of permissions.

Simple user‑role‑permission model:

However, as user count grows, a direct user‑permission mapping becomes unmanageable, prompting the classic RBAC model where roles bridge users and permissions.

2.3 Evolution of Permission Models

2.3.1 RBAC Model

Roles connect users and permissions in a many‑to‑many relationship, allowing flexible assignment.

This model scales well; a large company may need only a few hundred roles.

2.3.2 Role‑Inheritance RBAC (RBAC1)

Higher‑level roles inherit all permissions of lower‑level roles and can have additional permissions, matching hierarchical organizational structures.

Inheritance can be a tree (single parent) or a directed acyclic graph (multiple parents).

2.3.3 Constrained RBAC (RBAC2)

Constraints such as role mutual exclusion, cardinality limits, and prerequisite roles improve security.

Common constraints: role mutual exclusion, cardinality, prerequisite conditions.

Mutual exclusion example: a user cannot simultaneously hold both accountant and auditor roles.

Cardinality limits the number of users per role (e.g., only one super‑admin).

Prerequisite condition requires a lower‑level role before assigning a higher‑level role.

2.4 User Segmentation

2.4.1 User Groups

Groups aggregate users with similar responsibilities, allowing a role to be assigned to the group instead of each individual.

Groups differ from roles: groups are collections of users, while roles link users to permissions.

2.4.2 Organizations

Permissions can be aligned with organizational units; new hires automatically inherit permissions of their organization.

This also enables data‑level isolation between organizations.

2.4.3 Positions

Positions (e.g., finance director, accountant) map to specific roles; a user holds one position, while a position may map to multiple roles.

2.5 Ideal RBAC Model

The ideal model combines RBAC, RBAC1, RBAC2, user groups, organizations, and positions to handle large‑scale, complex business scenarios.

Choosing a simpler model is appropriate for small teams (under ten people).

3 Permission System Table Design

3.1 Standard RBAC Tables

The standard RBAC requires six tables: user, role, permission, user‑role relation, role‑permission relation, and optionally a permission‑group table.

用户-角色-权限

3.2 Ideal RBAC Tables

The ideal model expands the standard schema to include role constraints, role inheritance, user groups, organizations, and positions, resulting in a more complex ER diagram.

4 Conclusion

The article provides a detailed, step‑by‑step guide to permission model design, emphasizing that the appropriate model depends on company size, business complexity, and personnel count. Simpler models suffice for small teams, while larger organizations benefit from the comprehensive RBAC‑based approach.