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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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