Authorization Models (RBAC/ABAC)

Overview

Authorization decides what an authenticated user can actually do — RBAC and ABAC are the two dominant models, alongside DAC, MAC, and need-to-know as supporting concepts.

Key concepts

• RBAC: permissions by role
• ABAC: permissions by user/resource/environment attributes
• DAC, MAC, need-to-know

How it works

Authorization determines the resources, systems, applications, files, and actions an authenticated user is allowed to access — decisions should follow least privilege and need-to-know principles.

Role-Based Access Control (RBAC)

RBAC assigns permissions based on a user's job role. Users are placed into roles or groups, and each role gets a defined set of permissions — making access management easier since admins assign access to a group instead of configuring each user individually. Example roles: student, teacher, help desk technician, HR employee, network administrator, manager, database administrator.

Example: a school might use separate roles for students, teachers, office staff, and administrators — students can view their own grades and coursework, while teachers can view and edit grades for their assigned classes.

Attribute-Based Access Control (ABAC)

ABAC makes access decisions using attributes about the user, resource, action, and environment — department, job title, device type, location, time of day, security clearance, data classification, or account risk level. It's more flexible than RBAC because it can make detailed decisions based on changing conditions.

Example: a finance employee may access payroll data only if they're in the Finance department, using a managed device, on an approved network, during business hours. The same employee trying from an untrusted device or unusual location might be denied or asked for additional verification.

Other authorization concepts