Role-Based Access Control

Core RBAC separates user–role from permission–role assignment. A review permission can belong to a reviewer role whose membership changes with staffing, avoiding repeated individual assignments at every resource.

A role collects permissions rather than merely naming a user group. NIST’s strict model obtains permissions through roles. A system with many direct individual exceptions still needs to audit those additional paths despite displaying role labels.

References: [1]

A user may be assigned several roles while activating only a subset in one session. Assignment, current activation and permission for an operation are distinct relationships; login need not enable all possible authority at once.

Hierarchical RBAC adds permission inheritance through an ordering that need not be one linear chain. Effective rights include inherited permissions, not just direct entries. Core assignment, hierarchy and constraints are separable model components.

References: [1]

Static separation of duty constrains role assignments, such as excluding mutually incompatible responsibilities for one user. Dynamic separation constrains simultaneous role activation in a session. Defining two role names alone does not prevent either conflict.

A matching role need not be sufficient for access. NIST’s medical-record example allows additional constraints relating a doctor to the particular patient. RBAC does not require every role member to access every object unconditionally; policy must express the relevant restrictions.

References: [1]