Information Security 12 min read

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.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
Understanding RBAC Permission Models and Their Design in 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.

distributed systemsaccess controlPermission ManagementauthorizationRBACrole hierarchy
IT Architects Alliance
Written by

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.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.