Role hierarchy

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Role hierarchy" – news · newspapers · books · scholar · JSTOR (February 2024) (Learn how and when to remove this message)

In role based access control, the role hierarchy defines an inheritance relationship among roles. For example, the role structure for a bank may treat all employees as members of the ‘employee’ role. Above this may be roles ‘department manager’, and ‘accountant’, which inherit all permissions of the ‘employee’ role, while above ‘department manager’ could be ‘savings manager’, ‘loan manager’.

RBAC models generally treat the role hierarchy as either a tree (set theory), as in the 1992 RBAC model of Ferraiolo and Kuhn (FK), or a partially ordered set in the 1996 RBAC framework of Sandhu, Coyne, Feinstein, and Youman (SCFY). In object oriented programming terms, the tree role hierarchy is single inheritance, while the partial hierarchy allows multiple.^[1] When treated as a partial order, the role hierarchy example given above could be extended to a role such as ‘branch manager’ to inherit all permissions of ‘savings manager’, ‘loan manager’, and ‘accountant’.

Complications can arise when constraints such as separation of duties exist between roles. If separation of duty was used to prohibit personnel from holding both ‘loan manager’ and ‘accountant’ roles, then ‘branch manager’ could not inherit permissions from both of them. The NIST RBAC model, which unified the FK and SCFY models, treats the role hierarchy as a partial order, although RBAC products have not gone beyond the tree structured hierarchy.