Role-Based Access Control Models.¶
Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). Role-Based Access Control Models. IEEE Computer, 29(2), 38-47.
Cited by¶
5 citations across 5 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Access Control
- The policy model selection (DAC, MAC, RBAC, ABAC, ReBAC, or hybrid)
This sourceDefines the RBAC reference-model family (RBAC0–RBAC3) in which permissions attach to roles and principals acquire them via role membership, compressing principal-permission assignment and easing administration/review.
Supported in partVerified against the publisher's abstract
The Sandhu et al. abstract establishes RBAC as one role-based model family, so it backs only the RBAC item of this six-model list; it says nothing about DAC, MAC, ABAC, ReBAC or hybrid.
“This article explains why RBAC is receiving renewed attention as a method of security administration and review, describes a framework of four reference models developed to better understand RBAC and categorizes different implementations, and discusses the use of RBAC to manage itself.”
- The policy model selection (DAC, MAC, RBAC, ABAC, ReBAC, or hybrid)
- Coverage / Reachability
- Workflow design: every input case has at least one terminating branch; an input that reaches no terminal state is a coverage failure. Access control: every required action is permitted by at least one granted role; a required action no role permits is a coverage gap that breaks the workflow.
This sourceFoundational RBAC model in which permissions to actions are granted through roles, framing coverage as every required action permitted by at least one role.
Supported in partVerified against the publisher's abstract
Abstract frames RBAC as simplifying security administration through roles but never states the coverage proposition that a required action no role permits breaks the workflow.
“Security administration of large systems is complex, but it can be simplified by a role-based access control approach. This article explains why RBAC is receiving renewed attention as a method of security administration and review, describes a framework of four reference models developed to better understand RBAC and categorizes different implementations, and discusses the use of RBAC to manage itself.”
- Workflow design: every input case has at least one terminating branch; an input that reaches no terminal state is a coverage failure. Access control: every required action is permitted by at least one granted role; a required action no role permits is a coverage gap that breaks the workflow.
- Indirection
- Principle of Least Privilege
- In organizational governance, it appears as role-based access control and separation of duties — the same employee should not both approve and disburse a payment — and as need-to-know information compartments.
This sourceFoundational RBAC reference covering least privilege and separation of duties.
Supported in partVerified against the publisher's abstract
The abstract grounds RBAC as an approach to simplifying security administration, but it never mentions least privilege, separation of duties, the approve/disburse example, or need-to-know compartments.
“Security administration of large systems is complex, but it can be simplified by a role-based access control approach.”
- In organizational governance, it appears as role-based access control and separation of duties — the same employee should not both approve and disburse a payment — and as need-to-know information compartments.
Mechanisms¶
- Role-Based View
- Its strength is that minimization becomes ambient and cheap: a role's window is defined once and every access inherits it, which is the principle of least privilege
This sourceDefines permissions through roles and sessions and explains how RBAC can be configured so users receive only the permissions needed for their tasks.
- Its strength is that minimization becomes ambient and cheap: a role's window is defined once and every access inherits it, which is the principle of least privilege
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 3 of 5 citations: 3 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:b6c764fbdf55 · see in the full table