A role is a named bundle of permissions representing responsibilities or access rights. Assigning a role avoids granting individual permissions separately to every user or service. section 17.1.1
Role-based access control (RBAC) asks whether a subject has a role that permits the requested action. If the role allows it, access is granted; otherwise, access is denied. section 17.1.1
A role commonly groups permissions by responsibility:
- Employee: view the employee’s own profile. section 17.1.1
- Manager: view and edit reports for the manager’s team. section 17.1.1
- Admin: access everything. section 17.1.1
A role check at an endpoint
A token can carry a roles claim such as roles: ["manager"]. An endpoint can then require a particular role, as with Spring Security’s @PreAuthorize("hasRole('ADMIN')") on an administrative dashboard. section 17.1.1
Figure 17.2 Roles and their associated permissions in RBAC. Each role represents a bundle of permissions. A user assigned to a role automatically inherits all the permissions granted by that role. This structure simplifies access control but can become difficult to manage as permission needs grow more specific.
Visualize each role as a security badge that automatically inherits its associated permissions, while recognizing that increasingly specific needs make roles harder to manage. section 17.1.1
Roles are easy to understand and widely supported, but large systems can develop role explosion: narrowly tailored roles become difficult to name, manage, and audit. When access depends on attributes such as department, region, or request time, ABAC may fit better; when it depends on relationships, ReBAC may fit better. section 17.3
Distributed systems also require consistent enforcement. Every service should account for where authorization checks live, how identity information is shared, and how access is logged rather than blindly trusting another service. section 17.2
