Understanding RBAC Permission Models and Their Design in Distributed Systems
This article explains the fundamentals of permission management, detailing the RBAC0‑RBAC3 models, user‑role‑permission relationships, user groups, organizational and positional structures, and how to design database schemas and authorization workflows for complex distributed systems.
Preface
Permission management is a crucial component of any backend system, aiming to control access to resources and prevent risks such as operational errors or data leakage.
1. Permission Model
The most widely used permission design is the Role‑Based Access Control (RBAC) model.
1.1 RBAC0 Model
RBAC0 consists of three core elements—users, roles, and permissions—with many‑to‑many relationships between users and roles, and between roles and permissions.
The model emphasizes that users are the subjects that initiate operations, roles act as bridges linking users to permissions, and permissions define the resources that can be accessed.
1.2 RBAC1 Model
RBAC1 introduces hierarchical roles, allowing roles to inherit permissions from other roles. It supports both general inheritance (a partial order allowing multiple inheritance) and restricted inheritance (a tree‑structured single inheritance).
1.3 RBAC2 Model
RBAC2 adds constraint controls, such as separation of duties, mutual exclusion of roles, cardinality constraints, and prerequisite roles, to enforce stricter security policies.
1.4 RBAC3 Model
RBAC3 combines the features of RBAC0, RBAC1, and RBAC2, providing the most comprehensive permission management solution.
1.5 User Groups
When the number of users and role types grows, grouping users with similar attributes (e.g., all finance staff) simplifies administration: assigning a role to a group automatically grants it to all members.
User groups can be hierarchical (mirroring departments and positions) or flat, depending on organizational needs.
1.5.1 Organization
Linking organizations to roles allows users to inherit all roles of their organization, reducing manual work and enabling easy role adjustments when users change departments.
1.5.2 Position
Positions within an organization (e.g., director, accountant, cashier) have distinct permission sets; higher positions inherit more permissions.
1.6 Model with Organization / Position / User Group
Combining users, organizations, positions, and user groups yields a flexible permission model suitable for various scenarios.
2. Authorization Process
Authorization can be performed manually (admin assigns roles to users or users to roles) or through an approval workflow where users request roles and supervisors approve them.
3. Database Schema
The underlying tables reflect the many‑to‑many relationships among users, roles, permissions, organizations, and positions.
4. Permission Frameworks
Apache Shiro
Spring Security
Both frameworks can be used to implement the described models; their advantages and usage details are covered in subsequent articles.
5. Conclusion
Permission systems are foundational yet can become complex in multi‑system, multi‑user‑type environments. The core RBAC model remains stable, and extensions such as hierarchical roles, constraints, organizations, and user groups allow it to meet diverse business requirements.
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
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.