Understanding Permission Management and RBAC Models

In daily work, developers constantly encounter permission issues, such as needing network access, code repository rights, monitoring platform logins, and data query permissions, which can cause inconvenience and delays when approvals are required.

Permission management is crucial for company data security, ensuring that different roles and levels see only appropriate data and have suitable operation limits; for example, financial information should be accessible only to finance staff.

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

Permission Model

2.1 Permission Design

Permissions can be categorized by business type, such as data view and data modification, corresponding to page, menu, and button permissions in system design. Menus are hierarchical (e.g., first-level, second-level, third-level), and a tree structure is recommended for clarity when requesting permissions.

As shown below:

In this architecture, buttons are children of second-level menus, which are children of first-level menus, making permission requests clear.

2.2 Why Roles Are Needed

After clarifying the permission hierarchy, we need a way to assign permissions to users. Direct user‑permission assignment becomes cumbersome as the user base grows, leading to high maintenance costs. Introducing a role as an intermediary solves this, allowing many users to share the same role.

However, as the number of users increases, assigning permissions per user becomes impractical. Many users share the same set of permissions, so a role‑based approach (RBAC) is more efficient.

2.3 Evolution of Permission Models

2.3.1 RBAC Model

With roles, permissions are assigned to roles, and users acquire permissions through their roles. This many‑to‑many relationship is illustrated below:

The classic RBAC model reduces complexity, especially in large organizations where a few hundred roles can cover thousands of users.

2.3.2 Role‑Inheritance RBAC (RBAC1)

In hierarchical organizations, higher‑level roles inherit permissions from lower‑level roles (e.g., a finance director inherits all permissions of a finance supervisor). This inheritance allows flexible permission expansion while maintaining clear structure.

Inheritance can be represented as a tree or a directed acyclic graph, depending on whether a role can have multiple parents.

2.3.3 Constrained RBAC (RBAC2)

Additional constraints improve security, such as role mutual exclusion, cardinality limits, and prerequisite conditions. For example, a user cannot simultaneously hold both accountant and auditor roles.

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

2.4 User Grouping

2.4.1 User Groups

Creating groups of users with identical permission needs (e.g., all customer‑service staff) allows assigning a role to the group, simplifying mass permission distribution.

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

2.4.2 Organizations

Aligning permissions with organizational hierarchy automates permission assignment for new hires and simplifies role changes when employees move between departments.

2.4.3 Positions

Positions (e.g., finance director, supervisor) can be linked to roles, often in a one‑to‑one relationship with users but many‑to‑many with roles.

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.

Choosing the appropriate model depends on company size, business type, and user count; small teams may use simple user‑permission mappings, while larger enterprises benefit from the full RBAC hierarchy.

3 Permission System Table Design

3.1 Standard RBAC Table Design

To represent the 用户-角色-权限 relationships, create user, role, and permission tables plus two junction tables (user‑role and role‑permission). The ER diagram is shown below:

3.2 Ideal RBAC Table Design

The ideal RBAC model extends the standard design with additional tables for role constraints, user groups, organizations, and positions, as illustrated in the following ER diagram:

Key points include the role mutual‑exclusion table, which can enforce constraints at the role or permission level.

4 Conclusion

This article provides a comprehensive guide to designing permission models, emphasizing that the choice of model should align with company scale, business complexity, and personnel count. For small teams, a simple RBAC model suffices; larger organizations may need the full, extended model to manage permissions efficiently.