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

Why RBAC? Ease of administration – 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 – 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 – 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 – 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 – 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