Role hierarchy
It is proposed that this article be deleted because of the following concern:
If you can address this concern by improving, copyediting, sourcing, renaming, or merging the page, please edit this page and do so. You may remove this message if you improve the article or otherwise object to deletion for any reason. Although not required, you are encouraged to explain why you object to the deletion, either in your edit summary or on the talk page. If this template is removed, do not replace it. The article may be deleted if this message remains in place for seven days, i.e., after 21:21, 30 December 2024 (UTC). Find sources: "Role hierarchy" – news · newspapers · books · scholar · JSTOR Nominator: Please consider notifying the author/project: {{subst:proposed deletion notify|Role hierarchy|concern=Addressed sufficiently in the primary [[Role-based access control|role-based access control]] article; not independently notable to warrant a standalone page; to the extent one would have more to add to this article, it hasn't happened in the 16 years since its creation.}} ~~~~ |
 | This article needs additional citations for verification. (February 2024) |
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.
References
[edit]- ^ Ravi S. Sandhu', Edward J. Coynek, Hal L. Feinsteink and Charles E. Youman (26 October 1995). "Role-Based Access Control Mo dels" (PDF). csrc.nist.gov. NIST. Retrieved 15 February 2024.
{{cite web}}: CS1 maint: multiple names: authors list (link)