RBAC₀ through RBAC₃

The argument for roles, before the model

Start with what user/group access control cannot do. Suppose you must grant read on resource X to users {A, B} and read on resource Y to users {B, C}. That already needs two groups, with B in both. Add a third distinct grouping and you need a third group; the number of groups grows with the number of distinct access patterns, and in an organisation of any size that number becomes unmanageable long before anybody notices. This argument is combinatorial, not aesthetic, and it is the argument an examiner wants when they ask what is wrong with DAC — not "DAC is insecure".

RBAC's answer rests on a stability asymmetry. The set of users churns constantly: people join, leave, and change jobs every week. The set of roles is comparatively static, because roles describe the organisation's job functions, and a company changes what its jobs are far less often than it changes who holds them. So attach permissions to the stable thing and attach people to it separately.

A role is not a group, and the confusion costs marks. A group is a set of users — a naming convenience for subjects, and a DAC construct. A role is a bundle of permissions attached to a job function, which a user activates. Both relations are many-to-many: a user may hold several roles, and a role may be held by several users; a role may carry several permissions, and a permission may belong to several roles.

RBAC₀ — the four entities

The base model has exactly four:

1. User — a human being, or a machine identity acting as one.
2. Role — a job function within the organisation, carrying an authority and a responsibility.
3. Permission — an approval to act on one or more objects. The synonyms access right, privilege and authorization all mean this.
4. Session — a mapping between a user and an activated subset of the roles that user has been assigned.

The session is the entity learners leave out, and it is where the least privilege marks live. A user assigned four roles does not walk around holding all four: they open a session and activate only the role the current task needs. The session relation is temporary and one-to-many — one user, many concurrent or successive sessions — while user↔role and role↔permission are both many-to-many.

Permission granularity matters as much as the count. "May list a directory and modify existing files, but not create new ones" and "may append records but not modify existing ones" are the kinds of permission that a real design is graded on, and they are exactly the read-only versus read-write distinction the next lesson turns into an answer.

Worked example — a small clinic. Users: Dana, Femi, Priya. Roles: Receptionist (permissions: read the appointment schedule, create and amend bookings), Nurse (read the schedule, read a patient chart, append a chart note), Charge Nurse (everything a nurse has, plus approve a chart correction and read the staffing roster). Priya is assigned both Nurse and Charge Nurse. When she sits down to write ordinary chart notes she opens a session activating only Nurse — so a mistake, or a compromise of her workstation, cannot approve a chart correction. That is least privilege happening at a specific moment, not as a slogan.

RBAC₁ — hierarchies

A role may itself be treated as an object, which is what permits hierarchies. In a hierarchy a senior role inherits every right of the roles beneath it. Charge Nurse is senior to Nurse, so its own permission entry shrinks to only the two rights it adds; everything else is inherited. A role may inherit from several subordinates, and several roles may share one subordinate — so the structure is really a partial order, not a tree.

Inheritance is what makes the permission table tractable at scale. A real bank case study defined a role as position AND job function — 65 positions × 368 functions gives 23,920 potential roles, of which roughly 1,300 were actually used. Notice the consequence: roles in different functional areas have no hierarchical relationship at all, because the natural senior/junior line only runs between the same function at different positions.

RBAC₂ — constraints

Constraints are how organisational policy — as opposed to convenience — gets written down. There are three types:

• Mutually exclusive roles. A user may hold at most one of a named set, either permanently or per session. It is reinforced by mutually exclusive permission assignment, which requires the roles to have non-overlapping permissions. This is how separation of duties is enforced, and it raises the bar for fraud from one dishonest person to collusion.
• Cardinality. A maximum number: users per role, roles per user, roles activatable in one session, or holders of a particularly sensitive permission.
• Prerequisite roles. A role assignable only to a user who already holds some other specified role — usually a junior one, which pairs naturally with a hierarchy.

The 2×2 that makes the numbering obvious

RBAC₀ is the base. RBAC₁ adds hierarchies. RBAC₂ adds constraints. RBAC₃ has both. Memorise it as a grid on two independent axes and the numbering stops being something to guess at:

In a design answer, an explicit hierarchy and an explicit constraint set earn marks that a flat list of roles simply does not.