Role-Based Access Control Richard Newman (c) 2012 R. Newman

Why RBAC? Ease of administration Mental Model Least Privilege Move users in and out of roles Move access rights in and out of roles Single admin operation vs. one per object Very flexible Mental Model Roles define access Role captures – function, responsibility, trust, qualifications Matches intuitive understanding of the “why” of access Least Privilege Restricts access according to needs Separation of duty through constraints Allows restricting role binding

RBAC Models RBAC-1: Flat RBAC RBAC-2: Hierarchical RBAC Direct assignment to user with “role” or job function No hierarchy Multiple simultaneous active roles per user RBAC-2: Hierarchical RBAC Hierarchies Inheritance RBAC-3: Constrained RBAC (Hierarchy or No hierarchy, depending on model system) Constraints on role bindings RBAC-4: Symmetric RBAC Constraints and hierarchies NIST model

RBAC Elements Five elements Associations User – entity requesting access to object Has no access as user, only in role Role – package of permissions Assigned to users by association/binding Permission – grants access to operation on an object Operation – specific functions depending on object Object – anything containing information that a user may need to access, or an application a user may need to employ Associations Many-to-many user-to-role assignment Many-to-many permission-to-role assignment

Role Engineering Design of collection of roles for organization Positions, organizational structures, job functions Care required to enforce least privilege Requires testing Groups defined by roles Level of indirection User associates with role, role has permissions Role changes needed permissions, do once for role User changes role, do once to remove role association

Hierarchy and Inheritance Roles related in hierarchical structure Subordinate roles inherit rights from roles above Rights added as role becomes more specific Allows assignment of users to fewer roles Only most specific roles needed Multiple role associations Constraints Can preclude assignment of one role if another is assigned Multiple inheritance specifications

Flat RBAC (1) Assignments Reviews Rationale Users to roles (many-to-many) Permissions to roles (many-to-many) Multiple simultaneous active roles per user Reviews User-role Which roles are assigned to a user Which users are assigned to a role Rationale Features of traditional group-based systems Basic requirements for any RBAC model

Hierarchical RBAC (2) All RBAC-1 requirements, plus Hierarchy Partial order on roles (seniority) Senior role acquires permissions of its juniors May be inheritance hierarchy (activation of all junior roles), or activation hierarchy (no activation implied), or both Two sub-levels (continue through higher levels) a - General Hierarchical RBAC Arbitrary partial order b - Restricted Hierarchical RBAC Simplified structures only, e.g., trees Rationale Greatly simplifies administration of permission assignment Sub-levels recognize existing implementations and potential

Constrained RBAC (3) All RBAC-2 requirements, plus Constraints Enforce separation of duty (SOD) requirements Reduces fraud, malfeasance Spreads responsibility and authority for an action over multiple individuals Two types Static Disallow user-role assignment combinations Dynamic Disallow U-R combinations on a per-transaction basis Rationale Support for SOD Static is easier to test, dynamic is more flexible

Symmetric RBAC (4) All RBAC-3 requirements, plus Additional review User-role assignment (as in Flat RBAC) Permission-role assignment Which roles have a permission Which permissions are assigned to a role Rationale May be difficult to implement permission-role assignment efficiently in large-scale systems Still, considered intrinsic aspect of RBAC by some

Sessions User session Role activation Authentication Process tree/system use Role activation Automatic (all roles) Default + activate role Default + activate/deactivate role NIST requires that multiple active roles are supported

Implementation Issues Scaling Numbers of users, roles, permissions, associations supported Review of user-role assignment Review of permission-role assignment Revocation Occurs when user or permission removed from role When enacted? Immediately (even for current operations) Any future operations Any future sessions