Stop 04 · Core Security ConceptsTopics · 6/10

Access Control Models (RBAC, ABAC)

In short

Once a user is logged in, something has to decide what they can touch. RBAC and ABAC are the two most common ways to make those decisions without writing a thousand if-statements.

Role-Based Access Control assigns permissions based on job role; Attribute-Based Access Control makes decisions based on multiple attributes (user, resource, environment) — different levels of flexibility for controlling access.

The blob taps a key card on a hotel door lock that glows green, beside a housekeeping trolley.

Think of it like this

Hotel key cards

Housekeeping cards open every room on their floor, the manager's card opens everything: that's by role. Your guest card opens only room 304, only between check-in and check-out: that's by attributes like room, date and who you are.

Watch it happen

Roles or rules?

RBAC

Permissions attach to roles
Users get one or more roles
Simple to audit, can get coarse

ABAC

Rules check user, resource, context
e.g. same department, office hours
Very flexible, harder to reason about

Start with RBAC for most apps. Add attribute rules, like ownership or region, where roles alone get clumsy.

The big ideas

What you need to know

RBAC: who you are at work

Admin, editor, viewer. Change a role's permissions once and everyone with that role updates.

ABAC: the full context

Decisions use attributes like department, data sensitivity, time, device and location.

Least privilege

Give the smallest set of permissions that lets people do their job. Review it regularly.

Watch role creep

People change teams and keep old roles. Regular access reviews remove what they no longer need.

See it in code

Walk through the code

1type User = { id: string; role: "admin" | "doctor" | "nurse"; dept: string };2type PatientFile = { ownerDept: string; sensitive: boolean };3 4// RBAC: the role alone decides5const canEdit = (u: User) => u.role === "admin" || u.role === "doctor";6 7// ABAC: role plus attributes of the record and the request8function canView(u: User, r: PatientFile, hour: number) {9  if (u.role === "admin") return true;10  const sameDept = u.dept === r.ownerDept;11  const onShift = hour >= 8 && hour < 20;12  return sameDept && (!r.sensitive || u.role === "doctor") && onShift;13}

1/3The user and record each carry attributes we can make decisions on.

A hospital example. Doctors and nurses can view records from their own department during shift hours, but only doctors see sensitive ones.

Save yourself the pain

Common mistakes

Oops

Creating a new role for every single person.

Do this instead

Too many roles is as messy as none. Group people by job, and use attributes for the exceptions.

Oops

Scattering permission checks across hundreds of files.

Do this instead

Put policy logic in one place, like a policy module or service, so it's easy to review and test.

Your mission

Design access for a college portal

~30 min

Quick check

'Managers can approve expenses only for their own team, and only under 50,000 rupees.' Which model does this need?

Go deeper

1Design a simple RBAC model for a hypothetical organization's systems.
2Learn when ABAC's added flexibility is worth its added complexity over simpler RBAC.
3Understand why 'least privilege' should guide role/attribute design regardless of model.