After this lesson, you will be able to: Apply RBAC, ABAC, and least privilege to design a real-world access control scheme.
Once you know who the user is, you have to decide what they can do. This lesson covers the two main authorization models. RBAC and ABAC, and how to apply least privilege to a small organization.
RBAC groups permissions into roles (Admin, Editor, Viewer) and assigns roles to users. It's simple, scales to thousands of users, and is the default in almost every SaaS product. The cost: roles get bloated over time, and edge cases force role explosion ('Editor-but-can't-publish-on-Fridays').
ABAC evaluates rules against attributes of the user, resource, action, and context. Example: 'Allow if user.department == file.department AND time is during business hours AND user.country == 'US'.' Far more expressive than RBAC, but harder to audit and slower to evaluate. AWS IAM policies are a good real-world ABAC example.
Imagine a school management system. Map out the roles you'd need.
List the user types: students, teachers, principals, IT staff, parents
List the resources: grades, attendance, financial records, lesson plans
For each user × resource pair, decide: Read, Write, both, or neither
Group users with the same access into a role
Identify any role that needs a context rule (e.g., teachers can only see grades for students in their class)
Relationship-Based Access Control checks 'is this user related to this resource?' (e.g., the resource's owner, a member of its group). Google Drive uses ReBAC, your access depends on whether someone shared the file with you. ReBAC is rising in popularity because most real apps think in terms of relationships, not roles.
A hospital wants to allow doctors to access only patients assigned to them. Which model best fits?
Sign in and purchase access to unlock this lesson.