The idea: who may do what, decided two ways
Authentication says who you are. Authorization says what you may do. Every request to an app carries the same four things: a subject (the user), an action (read, write), a resource (a patient's chart) and an environment (the time, the network). A policy decision point turns them into PERMIT or DENY.
The page sends each request to two decision points. RBAC (role-based access control) asks whether one of the user's roles holds the needed permission. ABAC (attribute-based access control) runs rules that compare attributes of the subject, the resource and the environment, at the moment of the request.
RBAC: users, roles, permissions
The NIST RBAC model has three sets and two relations. User assignment (UA) links users to roles; permission assignment (PA) links roles to permissions, where a permission is an operation on an object type, such as record:read. A check follows the edges: user → role → permission. If a path exists, PERMIT.
That makes RBAC fast and easy to audit. "Who can read charts?" is answered by following the edges backwards. Admins grant access by adding a user to a role, not by editing code. The catch is that the check sees only the role and the object type, never the particular record or the time (Demo: doctor reads a chart in her ward, Demo: nurse tries to write a chart).
ABAC: rules over attributes
ABAC (NIST SP 800-162) writes the policy as rules. Each rule has an effect (Permit or Deny) and a condition over attributes: subject.job, subject.dept, resource.type, resource.dept, environment.time. A rule whose condition is false is NotApplicable. A combining algorithm turns the rule results into one decision. The page uses deny-overrides: any Deny wins, else any Permit, else the default Deny. XACML also has permit-overrides and first-applicable.
Because the rules read live values, a change of department or a different clock time changes the decision without anyone touching the policy (Demo: reading at 23:00, off shift).
Where they disagree
| request | RBAC (coarse roles) | ABAC | why |
|---|---|---|---|
| alice read rec-17, 09:00 | PERMIT | PERMIT (R1) | doctor, same ward, on shift |
| carol read rec-17, 09:00 | PERMIT | DENY | oncology doctor, cardiology chart: the role covers every chart |
| bob write rec-17, 09:00 | DENY | DENY | nurses read charts, they do not write them |
| alice read rec-17, 23:00 | PERMIT | DENY (R4) | off shift: a role has no clock |
| dave read inv-9 / rec-17 | PERMIT / DENY | PERMIT / DENY | billing sees invoices, not charts |
In this model RBAC is never stricter than ABAC: whenever ABAC permits, RBAC does too. The gap is over-permission, and it is exactly the "broken access control" of the OWASP Top 10: a user with the right role reaching a record that is not theirs (Demo: doctor from another ward).
Role explosion
RBAC can close the ward gap, but only with more roles: one per job and ward (cardio-doctor, onco-doctor, ...) and one permission per ward (cardio-rec:read, ...). With two wards that is 5 roles instead of 3. With 20 wards, 3 jobs and day and night shifts it is 120 roles, and every new ward means new roles, new permissions and new assignments (Demo: RBAC fix, one role per ward; also the Options menu).
Even then, the time of day cannot be a static role. NIST RBAC handles some context through sessions (a user activates a role only when needed) and constraints such as separation of duty, but a rule like "only during your shift" is an attribute test, and that is what ABAC is built for.
In practice: both
| RBAC | ABAC | |
|---|---|---|
| decision from | stored grants (UA, PA) | rules plus attribute values at request time |
| "who can read X?" | follow the edges | evaluate every user against the rules |
| fine grain (owner, ward, time) | more roles | one more condition |
| needs | a role directory | trustworthy attributes from the identity provider and the data |
Most real systems mix them: the role is just one more attribute (subject.job here), and rules add the record and context checks. AWS IAM adds tag conditions to role policies, Kubernetes uses RBAC, and engines such as Open Policy Agent, Cedar and XACML evaluate attribute rules. The identity and its attributes usually arrive in a token, see OAuth and JWT vs sessions.
What the page leaves out
Role hierarchies (a senior doctor inheriting the doctor role), sessions and separation-of-duty constraints from NIST RBAC are not drawn. ABAC here has four rules and one combining algorithm; real policies have targets, obligations (for example "log this access"), policy sets and break-glass rules for emergencies. Where attributes come from (the identity provider, the database row) and relationship-based models such as Google Zanzibar (ReBAC) are not shown.