Information Security 12 min read

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.

Architecture Digest
Architecture Digest
Architecture Digest
Permission System Design and RBAC Models

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.

backendaccess controlsecurityPermission ManagementRBACrole hierarchy
Architecture Digest
Written by

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.

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.