In our last post we covered Access Control broadly — the matrix, ACLs, capabilities, and a first look at Role-Based Access Control (RBAC). Today we're going deeper into one specific piece of RBAC that makes it practical at real organizational scale: role hierarchies.

The core idea is simple: instead of assigning every permission to every role individually, let roles inherit from other roles. A manager automatically gets everything an employee has, plus more. This single idea is what keeps large RBAC deployments from turning into spreadsheets of redundant permissions.

The RBAC Family: RBAC0 through RBAC3

RBAC isn't one single model — it's a family of four, each adding a capability on top of a common base. This framework comes from Sandhu, Ferraiolo, and Kuhn's foundational NIST work on RBAC.

  • RBAC0 — the minimum functionality: users, roles, permissions, and sessions
  • RBAC1 — RBAC0 plus role (permission) inheritance — this is role hierarchies
  • RBAC2 — RBAC0 plus constraints (restrictions on role assignment)
  • RBAC3 — the consolidated model: RBAC0 plus both hierarchies and constraints
RBAC model family overview
Figure 1: RBAC1 (hierarchies) and RBAC2 (constraints) both extend the RBAC0 base; RBAC3 combines both.

As one of the field's own authors put it plainly: the term RBAC doesn't have one universally agreed meaning — different vendors and products implement pieces of this family differently. That's worth keeping in mind whenever you compare "RBAC support" across two products.

The Core RBAC0 Building Blocks

Before hierarchies make sense, it helps to be precise about the four entities RBAC is built from:

  • User — an individual with a unique ID who has access to the system
  • Role — a named job function that signals a certain authority level
  • Permission — equivalent to an access right (what BLP would call read, write, execute...)
  • Session — a mapping between a user and the set of roles that user has activated for that session
RBAC0 building blocks and role hierarchy
Figure 2: Users are assigned to roles, roles are assigned permissions, and a role hierarchy sits above it all.

Sessions matter more than they first appear to. A user might be assigned five roles overall but only activate two of them in a given session — the classic principle of least privilege in action. You don't want your database administrator role "on" while you're just reading email.

What a Role Hierarchy Actually Does

A role hierarchy is a partial ordering of roles based on how much access they carry. If role B sits above role A in the hierarchy, B inherits every permission A has — plus whatever is assigned directly to B.

This mirrors how real organizations already think about authority. Consider an engineering department:

  • The Director has the most privileges
  • Each role inherits all privileges from the roles below it
  • A role can inherit from more than one role at once
  • Additional privileges can still be layered onto any individual role
Engineering department role hierarchy
Figure 3: A Director inherits from both Project Leads, who each inherit from their Engineers, down to the shared Engineering Dept role.

Notice that Project Lead 1 and Project Lead 2 don't inherit from each other — the hierarchy only flows upward through direct lines. This is what makes it a partial ordering rather than a strict, single-path chain: multiple roles can converge into one higher role without being directly comparable to each other.

Case Study: Role Hierarchies at a Bank

A financial-analyst role hierarchy makes the payoff of inheritance concrete. Picture a bank with the following official positions, all doing financial-analyst work: Clerk, Group Manager, Head of Division, Junior, Senior, Specialist, and Assistant. Without inheritance, each of these roles would need its own full list of permitted access rights per application — money market instruments, derivatives trading, interest instruments, and more.

With a strict ordering — say, role B has strictly more access than role A — the permission table collapses dramatically:

Permission table with and without inheritance
Table 1: Inheritance means each higher role's table only needs to list its additional rights, not the full set.

This is the real-world payoff of role hierarchies: administrators maintain a handful of incremental differences between roles instead of re-specifying every permission from scratch for every position.

Constraints: The Other Half of the Story (RBAC2)

Hierarchies answer "what does this role inherit?" Constraints answer a different question: "what combinations of roles or assignments should never be allowed?" Three constraint types show up repeatedly:

  • Mutually exclusive roles — a user can hold only one role from a defined set (e.g., Purchasing Agent and Accounts Payable should never be the same person — classic separation-of-duties)
  • Cardinality — a cap on how many users can hold a given role at once (e.g., only one Department Chair)
  • Prerequisite roles — a user can only be assigned a role if they already hold some other role first (you can't be a Senior Analyst without having been a Junior Analyst)

RBAC3 is simply what you get when you run RBAC1 and RBAC2 together — a role hierarchy for efficient permission management, plus constraints for security guarantees like separation of duties.

Where This Shows Up in Real Systems

Role hierarchies aren't just an academic construct — they're implemented across mainstream platforms:

  • Windows NT and onward, via global and local groups
  • IBM's OS/400
  • Oracle databases
  • The .NET framework

In a typical enterprise rollout, role hierarchies also show up organizationally, not just technically. HR assigns user IDs to roles based on job function and position; application administrators separately map access rights to applications; and an authorization-administration layer connects the two by binding roles to the applications they're allowed to touch. This three-way split — HR, application admin, authorization admin — is exactly why RBAC scales in large enterprises where no single team owns both "who someone is" and "what a system can do."

The takeaway: role hierarchies are what let RBAC model real organizational structure instead of fighting it. Permissions follow authority naturally, and administrators only ever have to define what changes between one level and the next.