Design of Permission System and RBAC Models

Permission System Design

Introduction

Permission management is a critical component of any backend system, aiming to control resource access for different users and prevent risks such as operational errors or data leakage.

1. Permission Model

The most widely used model is Role‑Based Access Control (RBAC).

1.1 RBAC0 Model

RBAC0 defines three core entities—users, roles, and permissions—where users and roles have a many‑to‑many relationship, and roles and permissions also have a many‑to‑many relationship.

User : The actor that initiates operations; can be B2B or B2C users, internal staff, or external customers.

Role : Acts as a bridge linking users and permissions; a user can have multiple roles, and each role can contain multiple permissions, which greatly reduces administrative effort in large systems.

Permission : The resources a user may access, including page, operation, and data permissions.

Page Permission : Determines which menus/pages a user can view.

Operation Permission : Controls actions such as view, add, edit, delete, and audit on UI elements.

Data Permission : Restricts the data visible to a user based on organizational scope (e.g., department, city).

1.2 RBAC1 Model

This model introduces hierarchical roles, allowing role inheritance with either unrestricted (multiple inheritance) or restricted (tree‑structured) relationships.

1.3 RBAC2 Model

RBAC2 adds constraints for separation of duties, including static and dynamic separation, mutual exclusion, cardinality limits, and prerequisite roles.

Mutual Exclusion : A user can be assigned at most one role from a mutually exclusive set.

Cardinality Constraint : Limits the number of users per role, roles per user, and permissions per role.

Prerequisite Role : A higher‑level role can be granted only after acquiring its lower‑level role.

1.4 RBAC3 Model

The most comprehensive model, integrating RBAC0, RBAC1, and RBAC2 features.

1.5 User Groups

When user count and role variety grow, users with similar attributes can be grouped; assigning a role to a group automatically grants it to all members, simplifying administration.

1.5.1 Organization

Linking organizations to roles enables automatic role assignment and data‑scope control based on organizational hierarchy.

1.5.2 Position

Different positions within the same department have distinct permission sets; higher‑level positions inherit more privileges.

1.6 Model with Organization/Position/User Group

The model can be adjusted for single‑system or distributed‑system scenarios, adding or removing relationships as needed.

2. Authorization Process

Authorization can be performed manually (admin assigns roles to users or users to roles) or via approval workflow (users request roles and managers approve).

3. Table Structure

The diagram shows a typical multi‑system database schema for storing users, roles, permissions, organizations, positions, and groups.

4. Permission Frameworks

Apache Shiro

Spring Security

Both frameworks can be adopted; their advantages, disadvantages, and usage details will be covered in future articles.

5. Conclusion

The permission system is foundational yet can become complex in large, multi‑system environments; however, the core RBAC concepts remain unchanged and can be extended to meet specific business needs.

If you found this article helpful, please give it a read again—thank you for your support!