Mastering RBAC: From Basic Models to Advanced Permission Architectures

Permission Model Overview

Permission management controls access to resources in backend systems. The most widely used design is Role‑Based Access Control (RBAC). RBAC0 defines three core entities—users, roles, permissions—with many‑to‑many relationships between users‑roles and roles‑permissions.

Users are subjects (internal staff or external customers). Roles act as bridges linking users to permissions, allowing a user to inherit multiple permissions through multiple roles. Direct user‑permission assignment is feasible only for small user bases; otherwise roles are required.

RBAC1 – Hierarchical Roles

RBAC1 adds role inheritance. Roles can inherit permissions from parent roles. Both unrestricted multiple inheritance and restricted single‑inheritance (tree) structures are supported.

RBAC2 – Separation‑of‑Duty Constraints

RBAC2 introduces static and dynamic constraints to enforce separation of duties.

Mutually exclusive roles : a user can be assigned at most one role from a conflicting set.

Cardinality constraints : limits on number of users per role, roles per user, or permissions per role.

Prerequisite roles : a higher‑level role can be granted only after the user holds a lower‑level role.

RBAC3 – Comprehensive Model

RBAC3 combines RBAC0, RBAC1, and RBAC2, providing a full‑featured permission architecture.

User Groups, Organizations, and Positions

When the number of users and roles grows, grouping users with similar attributes simplifies administration. Assigning a role to a group automatically grants that role to all members.

Hierarchical groups : parent‑child relationships mirroring organizational structures.

Flat groups : groups without hierarchy, useful for cross‑department collaborations.

Organizations (departments) can be linked to roles. When a user joins an organization, they inherit all roles associated with that organization, reducing manual assignment.

Positions within a department (e.g., director, accountant, cashier) have distinct permission sets; higher‑level positions inherit more permissions.

Combined Model

Integrating users, roles, permissions, groups, organizations, and positions yields a flexible architecture suitable for both simple and complex systems.

Authorization Process

Authorization can be performed manually or via an approval workflow.

Manual authorization : administrators assign roles to users (or users to roles) through the permission‑center UI.

Approval authorization : users request a role through an OA process; a manager approves the request and the role is granted automatically.

Database Schema

A typical relational schema includes tables for users, roles, permissions, user_role, role_permission, groups, organizations, positions, and their association tables. The diagram below shows a simplified multi‑system schema.

Implementation Frameworks (Java)

Common Java frameworks for implementing RBAC are Apache Shiro and Spring Security. The choice depends on project requirements such as simplicity, feature set, and integration needs.

Conclusion

RBAC provides a stable foundation for permission systems. Extensions such as hierarchical roles, separation‑of‑duty constraints, user groups, organizations, and positions allow the model to scale to large, distributed environments.

Code example

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*