RoleBased Access Control Richard Newman c 2012 R

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