Why Permission Management Matters: Designing Effective RBAC Models

1 Why Permission Management is Needed

In everyday work, permission issues accompany us constantly. New developers must request various permissions such as network access, code repository commit rights, monitoring platform login, and data query permissions. While these requests can be cumbersome, strict permission management is essential to protect sensitive data and prevent unauthorized changes.

For example, a payment company's operations backend contains merchant information, legal entity data, transaction records, and fee configurations. If every employee could access all this data, they could alter fee rates, causing huge losses.

Similarly, merchant data is highly confidential; a malicious employee could sell it to competitors, harming the business. Even though such breaches are individual acts, a well‑designed permission system can prevent the data from being exposed in the first place.

Overall, permission management guarantees data security by ensuring that different roles see only the data they need. Financial data is limited to finance staff, configuration data to operations staff, and so on, reducing unnecessary security risks.

2 Permission Model

2.1 Permission Design

Permissions can be classified by business type, such as data view or data modification, which correspond to page, menu, and button permissions in a system. Menus may have multiple levels; for example, the CSDN article editor has a two‑level menu. Designing permissions as a tree structure makes it easy to understand required permissions.

Below is an illustration of a hierarchical menu:

In this architecture, a button’s parent is a second‑level menu, whose parent is a first‑level menu, allowing users to clearly see which permissions they need.

2.2 Why Roles Are Needed

After clarifying the permission hierarchy, we must decide how to assign permissions to users. With few users, permissions can be assigned directly, resulting in a many‑to‑many user‑permission relationship:

As the number of users grows, this model becomes unmanageable. Many users share the same set of permissions, so we introduce a third entity—roles—to which permissions are assigned, and users are linked to roles. This is the classic Role‑Based Access Control (RBAC) model.

2.3 Evolution of Permission Models

2.3.1 RBAC Model

In RBAC, a role can have multiple permissions, a permission can belong to multiple roles, and a user can have multiple roles. This many‑to‑many relationship reduces maintenance effort.

Roles also simplify large organizations: a company with tens of thousands of employees may need only a few hundred roles.

However, real‑world businesses often require hierarchical permissions, where higher‑level positions inherit lower‑level permissions.

2.3.2 Role‑Inheritance RBAC (RBAC1)

Role‑inheritance RBAC allows an upper‑level role to inherit all permissions of its subordinate roles while adding extra permissions. This matches organizational structures such as finance director > finance manager > cashier.

Two possible role hierarchies exist: a tree where each lower role has a single parent, and a directed acyclic graph (DAG) where roles can have multiple parents.

2.3.3 Constrained RBAC (RBAC2)

Constraints improve security, such as mutually exclusive roles, cardinality limits, and prerequisite conditions. For example, a user cannot simultaneously hold both accountant and auditor roles.

2.4 User Grouping

2.4.1 User Groups

Creating roles solves the problem of assigning permissions to many users. When a large number of users share the same role, a user group can be defined, and the role is assigned to the group, automatically granting the permissions to all members.

User groups differ from roles: groups are collections of users, while roles bridge users and permissions.

2.4.2 Organizations

Permissions can also be aligned with an organization’s hierarchy. Members of the same department often need the same base permissions, and assigning roles by organization enables automatic permission updates when users join, leave, or change departments.

2.4.3 Positions

Within an organization, different positions (e.g., finance director, manager, accountant) require different permissions. Positions can be linked to roles, allowing fine‑grained control.

2.5 Ideal RBAC Model

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

This comprehensive structure can be simplified for small companies (under ten employees) where a simple user‑permission model suffices.

3 Permission System Table Design

3.1 Standard RBAC Table Design

The standard RBAC schema requires six tables: users, roles, permissions, user‑role, and role‑permission relationships.

user‑role‑permission

3.2 Ideal RBAC Table Design

The ideal model extends the standard schema with additional tables for role constraints, groups, organizations, and positions.

Role‑mutual‑exclusion tables are especially important for enforcing security policies.

4 Conclusion

The article provides a detailed, step‑by‑step guide to designing permission models, recommending RBAC for companies with up to a thousand employees and more advanced models for larger, more complex organizations. The best model is the one that fits the specific size, business type, and personnel structure of the company.