Understanding RBAC: Role‑Based Access Control Models for Secure Spring Applications

1. Introduction

Welcome to the Spring Security practical series. After covering basic authentication and endpoint protection, we now need a complete permission management system, which requires understanding RBAC (Role‑Based Access Control).

2. Why Use RBAC?

Systems often have users with different access levels, such as paid versus free users. As business requirements grow—introducing tiers like VIP1 and VIP2—simple permission checks become insufficient. RBAC adds a role layer that groups users with similar permissions, improving extensibility and reducing repetitive permission assignments.

By assigning permissions to roles instead of individual users, bulk permission changes become simple, and the coupling between users and resources is minimized.

3. RBAC Model Variants

There are four RBAC models: RBAC0, RBAC1, RBAC2, and RBAC3. RBAC0 is the basic model; the others extend it.

3.1 RBAC0

RBAC0 defines the minimal set for an RBAC system and consists of four components:

User – the subject of permissions.

Role – a collection of permissions.

Session – the intermediary that binds a user to roles.

Permission – an access right to a specific resource.

3.2 RBAC1

RBAC1 adds role inheritance, allowing hierarchical relationships where a parent role inherits all permissions of its child roles.

3.3 RBAC2

In sports you cannot be both player and referee simultaneously.

RBAC2 introduces two constraints on top of RBAC0:

SSD (Static Separation of Duty) : prevents a user from being assigned conflicting roles, limits the number of roles per user, or enforces conditional role assignment.

DSD (Dynamic Separation of Duty) : restricts role activation during a session based on runtime conditions.

These constraints enhance security by preventing role conflicts.

3.4 RBAC3

I want it all!

RBAC3 combines the features of RBAC1 and RBAC2, offering both inheritance and separation‑of‑duty constraints.

4. Key RBAC Concepts

4.1 User

A user can be an individual, a group, a virtual account, a client, or even a third‑party application—any entity that needs to access resources.

4.2 Role

A role is a container of permissions. Users and groups can belong to multiple roles, and roles can be hierarchical.

4.3 Permission

Permissions (or access rights) are atomic units that control access to resources, typically enforced at the API level and can be mapped to menus or UI buttons.

5. Conclusion

RBAC has become a primary method for fine‑grained access control. By defining users, roles, sessions, and permissions, you can align access rights with organizational responsibilities, granting only the necessary privileges. Mastering RBAC is essential regardless of the security framework you use.