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