Understanding RBAC Permission Models and Authorization Processes

The most widely used permission design is the Role‑Based Access Control (RBAC) model, which defines users, roles, and permissions with many‑to‑many relationships. RBAC0 is the basic model that connects users to roles and roles to permissions.

Roles act as a bridge, allowing a user to inherit multiple permissions through multiple roles, which greatly reduces administrative effort in large‑scale systems.

RBAC1 adds hierarchical roles, supporting both general (multiple inheritance) and restricted (single‑inheritance tree) relationships, enabling role grouping and simplification of permission management.

RBAC2 introduces constraints such as separation of duties (static and dynamic), mutually exclusive roles, cardinality limits, and prerequisite roles, ensuring that users cannot acquire conflicting permissions.

RBAC3 combines the features of RBAC0, RBAC1, and RBAC2 into a comprehensive model.

User groups allow administrators to assign roles to a collection of users sharing common attributes (e.g., all finance staff), reducing repetitive role assignments. Groups can be hierarchical (departments, positions) or flat, depending on organizational needs.

Organizations and positions can be linked to roles; when a user joins an organization or assumes a position, they automatically inherit the associated roles and data permissions, simplifying role management across multiple systems.

A combined model that incorporates users, roles, permissions, groups, organizations, and positions can be visualized as shown below, with relationships adapting to system complexity.

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

The article also provides a simple multi‑system database schema to store users, roles, permissions, groups, organizations, and their relationships.

Various permission frameworks can be adopted in projects, each with its own pros and cons, which will be discussed in future articles.

In conclusion, while permission systems can become complex in large, multi‑system environments, the core RBAC concepts remain stable and can be extended to meet specific business requirements.