Mastering RBAC: From Basic Models to Advanced Permission Design

1. Permission Model

Permission management is essential for backend systems to control access to resources and prevent risks such as erroneous operations or data leaks.

In a micro‑service architecture the permission system is isolated and serves multiple business systems (product center, order center, user center, warehouse, mini‑programs, apps, etc.).

1.1 RBAC0 Model

The most widely used model is Role‑Based Access Control (RBAC). It consists of users, roles, and permissions, with many‑to‑many relationships between users‑roles and roles‑permissions.

User is the entity that initiates operations; it can be a B2B or B2C user, an internal employee, or a cloud service customer.

Role bridges users and permissions; a role can contain many permissions and a user can have many roles.

Directly assigning permissions to users works for small user bases, but for large enterprises role‑based assignment greatly reduces administrative effort.

Permission includes page, operation, and data permissions.

Page permission : controlled by menus; if a user has access to a menu, the corresponding page is accessible.

Operation permission : controls actions such as view, add, edit, delete, approve; the backend checks whether the user's role includes the required operation.

Data permission : limits the data visible to a user, e.g., finance department sees only its own department data.

1.2 RBAC1 Model

Introduces hierarchical roles. General inheritance allows multiple parent roles; restricted inheritance enforces a tree structure with single inheritance, simplifying role management.

1.3 RBAC2 Model

Adds separation‑of‑duty constraints, including mutually exclusive roles, cardinality limits, and prerequisite roles.

1.4 RBAC3 Model

Combines RBAC0‑RBAC2 features into a comprehensive model.

1.5 User Groups

When user count and role types increase, grouping users with similar attributes (e.g., all finance staff) into a user group allows assigning roles to the group instead of each individual.

User groups can be hierarchical (linked to organization/position) or flat.

1.5.1 Organization

Associating organizations with roles enables automatic role assignment when a user joins an organization and simplifies data‑permission control.

1.5.2 Position

Different positions within the same department have different permissions; higher positions inherit more permissions.

1.6 Model with Organization / Position / User Group

Combines the above concepts into a flexible permission model; relationships may vary depending on system complexity.

2. Authorization Process

Authorization grants roles to users and can be performed manually or via an approval workflow.

Manual authorization : Administrator adds roles to a user or adds users to a role through the permission console.

Approval authorization : Users request a role through an OA process; after supervisor approval the role is granted automatically.

3. Database Schema

A multi‑system schema illustrating tables for users, roles, permissions, organizations, positions, and user groups.

4. Permission Frameworks

Apache Shiro

Spring Security

Both frameworks can be used; their advantages and usage will be covered in future articles.

5. Conclusion

The permission system is both fundamental and potentially complex. While the core RBAC model remains unchanged, it can be extended to meet the needs of multiple systems, user types, and scenarios.