Permission System Design and RBAC Models
This article explains the fundamentals of permission system design, covering the core RBAC0 model, its extensions RBAC1, RBAC2, RBAC3, as well as user groups, organizational structures, authorization processes, database schema considerations, and common implementation frameworks for secure backend access control.
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 leaks.
The author, responsible for permission design in a micro‑service architecture, describes how the permission system is isolated and serves multiple business services like product, order, user, warehouse, mini‑programs, and various apps.
1. Permission Models
The most widely used model is RBAC (Role‑Based Access Control). The basic RBAC0 model consists of users, roles, and permissions, with many‑to‑many relationships between users‑roles and roles‑permissions.
Users are the subjects that perform operations; roles act as bridges linking users to permissions; permissions define accessible resources such as pages, actions, and data.
Direct user‑permission assignment works for small user bases, but in large enterprises role abstraction greatly reduces administrative effort and improves scalability.
1.1 RBAC0
Describes users, roles, and permissions and explains why roles are essential for managing large numbers of users with similar access needs.
1.2 RBAC1
Introduces hierarchical roles, allowing role inheritance (both unrestricted and tree‑structured) to simplify permission management.
1.3 RBAC2
Adds separation‑of‑duty constraints, including mutually exclusive roles, cardinality limits, and prerequisite roles.
1.4 RBAC3
Combines RBAC0, RBAC1, and RBAC2 into the most comprehensive model.
1.5 User Groups
When user numbers and role types grow, grouping users with similar attributes (e.g., all finance staff) allows administrators to assign roles to the group, automatically granting them to members.
1.5.1 Organization
Organizations can be linked to roles so that users inherit all roles of their organization, simplifying onboarding and transfers, and also controlling data permissions.
1.5.2 Position
Positions within an organization (e.g., director, accountant) have distinct permission sets; higher positions inherit more permissions.
1.6 Model with Organization/Position/User Group
Combines users, roles, permissions, organizations, positions, and user groups into a flexible schema that can be adjusted for single‑system or distributed‑system scenarios.
2. Authorization Process
Authorization can be manual (admin assigns roles to users or users to roles) or approval‑based (users request roles via an OA workflow that is approved by supervisors).
3. Database Schema
Provides a high‑level table design for multi‑system environments, illustrating many‑to‑many and one‑to‑one relationships among users, roles, permissions, organizations, positions, and user groups.
4. Permission Frameworks
Apache Shiro
Spring Security
Either framework can be adopted, with their pros and cons to be discussed in future articles.
5. Conclusion
The permission system is foundational yet can become complex in real projects involving multiple systems, user types, and scenarios; however, the core RBAC model remains unchanged and can be extended to meet specific requirements.
Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.