1. ISA 562 Information Security Theory and Practice
Role-based Access Control

2. References NIST documents at http://csrc.nist.gov/rbac/
D. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, R. Chandramouli, "A Proposed Standard for Role Based Access Control (PDF)," ACM Transactions on Information and System Security , vol. 4, no. 3 (August, 2001) - draft of a consensus standard for RBAC.
The ARBAC97 model for role-based administration of roles (1999)

3. Discretionary AC
Restricts access to objects based solely on the identity of users who are trying to access them.
Individuals
Resources
Server 1
Server 3
Server 2
Application
Access List
Legacy Apps
Name Access
Tom Yes
John No
Cindy Yes

4. Mandatory AC
MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance.
Principle: Read Down Access
equal or less Clearance
Write Up Access
equal or higher Clearance

5. Mandatory AC (cont) Users Resources Server 1 “Top Secret” Server 2
“Classified”

6. Role-Based AC Individuals Roles Resources Role 1 Role 2 Role 3
Server 1
Server 2
Server 3
User’s change frequently, Roles don’t

7. Role-Based AC
A user has access to an object based on the assigned role.
Roles are defined based on job functions.
Permissions are defined based on authorities and responsibilities of a job.
Operations on an object are invocated based on the permissions.

8. Role-Based AC Framework
Core Components
Constraining Components
Hierarchical RBAC
General
Limited
Separation of Duty Relations
Static
Dynamic

9. Core Components Defines: USERS ROLES OPERATIONS (ops) OBJECTS (obs)
Permissions: (operation, object) pairs
User-to-Role Assignments (ua)
assigned_users
Sessions

10. RBAC Core user_sessions session_roles (UA) User Assign- ment (PA)
Permission
Assignment
USERS
OBS
OPS
SESSIONS
ROLES
PRMS

11. USERS Process People: Processes: Alice Intelligent Agent Bob
Cindy
Processes:
Intelligent Agent
mailer daemon
A mal-ware process

12. OBS (objects)
An entity that contains or receives information, or has exhaustible system resources.
Examples:
OS Files or Directories
DB Columns, Rows, Tables, or Views
Printer
Disk Space
Lock Mechanisms
RBAC will deal with all the objects listed in the permissions assigned to roles.

13. ROLES
An organizational job function with a clear definition of inherent responsibility and authority (permissions).
Director
Developer
Budget Manager
Many-to-many relation between
Users & Permissions
Help Desk
Representative

14. OPS (operations)
An execution of an a program specific function that’s invocated by a user.
Examples:
Object – Operations ….
Database – Update Insert Append Delete
Locks – Open Close
Reports – Create View Print
Applications - Read Write Execute
SQL

15. PRMS (permissions) Perms ⊆ 2 OBJ x ACTIONS
The set of permissions that each grant the approval to perform an operation on a protected object.
User.DB1
View
Update
Append
permissions
object
User.F1
Read
Write
Execute
permissions
object
Perms ⊆ 2 OBJ x ACTIONS

16. Some Notation: Four Predicates
UA(u,r): says that user u is assigned to role r.
PA(r,(op,ob)): says that role r is permitted to execute operation op on object ob.
user-session(u,s): says that user u has opened session s.
session-role(s,r): iff says that some user has invoked the role r within session s.

17. Constraint Components - 1
Role Hierarchies
Based on role inheritance.
R1 is a senior to R2 (written R1 > R2 ) iff
All permissions assigned to R2 are available to R1.
> is a partial order on the set of roles

18. Some Consequences UA(u,r1) and r1 > r2  UA(u,r2)
PA(r2,(ob,op)) and r1 > r2  PA(r2,(ob,op))
session-role(s,r1) and r1 > r2  session-role(s,r1)

19. Role Hierarchy & Constraints
user_sessions
(RH)
Role Hierarchy
session_roles
(UA)
User Assign-
ment
(PA)
Permission
Assignment
USERS
OBS
OPS
SESSIONS
ROLES
PRMS
SSD
DSD

20. Separation of Duty Constraints
Two kinds:
Static separation of duty
Determined when users are assigned to roles
Affects the UA(user,role) predicate
Dynamic separation of duty
Constraints the roles invoke-able by a user
Affects the session-role(session,role) predicate directly, and consequently the permissions available to a user.

21. Specifying Constraints
staticConflict(r1,r2): says that roles r1 and r2 have a static conflict
Implying that they should not be assigned to the same user
dynamicConflict(r1,r2): says that roles r1 and r2 have a dynamic conflict
Implying that they should not be invoked in the same session by the same user
The same user may invoke roles r1 and r2 in different sessions!

22. A Hierarchy of RBAC Models
Least Privileged
Separation of Duties
Models
Hierarchies
Constraints
RBAC0 No
RBAC1
Yes
RBAC2
RBAC3
Most
Complex
RBAC3
Effort
RBAC Model

23. RBAC System and Administrative Functional Specification
Administrative Operations
Create, Delete, Modify and Maintain elements and relations of the RBAC model
Administrative Reviews
Query operations
System Level Dynamic Functions
Creation of user sessions
Role activation/deactivation
Constraint enforcement
Computing Access Decisions

24. UA (user assignment) USERS set ROLES set
A user can be assigned to one or more roles
Developer
A role can be assigned to one or more users
Help Desk Rep
UA ⊆ Users X Roles:
Example: UA(Alice, Developer), UA(Bob, Help Desk Rep)

25. UA (user assignment)
Mapping of role r onto a set of users
ROLES set
USERS set
User.F1
User.F2
User.F3
User.DB1
View
Update
Append
User.DB1
permissions
object
assigned_user(r) gives the set of users assigned to the role r
assigned_user(r)={u:UA(u,r)}
assigned_user: ROLES  2USERS
User.DB1

26. PA (perms assignment) PA ⊆ USERS x Permissions ROLES set PRMS set
A perms can be assigned to one or more roles
Create
Delete
Drop
Admin.DB1
View
Update
Append
A role can be assigned to one or more perms
PA ⊆ USERS x Permissions
User.DB1

27. PA (perms assignment) assigned_permissions(r) gives the
Mapping of role r onto a set of permissions
PRMS set
ROLES set
Read
Write
Execute
View
Update
Append
Create
Drop
SQL
User.F1
User.F2
User.F3
Admin.DB1
assigned_permissions(r) gives the
set of permissions assigned to role r
assigned_permissions(r) = {p : PA(r,p)}
assigned_permissions: ROLES  2 PERMS

28. PA (perms assignment) READ Mapping of operations to permissions
OPS set
PRMS set
public int read(byteBuffer dst)
throws IOException
Inherited methods from java.nio.channls
close()
isOpen()
READ
Gives the set of operations associated with the permission. Namely, those that have the permission!
op(p: PERMS)  {op∈ OPERATION: p=(obj,op)}

29. PA (perms assignment) Mapping of permissions to objects Objects
PRMS set
Open
Close
View
Update
Append
Create
Drop
BLD1.door2
SQL
Gives the set of objects with the permission
DB1.table1
ob(p: PERMS)  {ob∈ OBJECT: p=(obj,op)}

30. SESSIONS The set of sessions that each user invokes. SESSION USER SQL
guest
user
admin
invokes
USER
FIN1.report1
SQL
DB1.table1
APP1.desktop

31. SESSIONS The mapping of user u onto a set of sessions. USERS SESSION
guest
user
admin
invokes
User2.FIN1.report1.session
USER1
SQL
User2.DB1.table1.session
USER2
User2.APP1.desktop.session
user_sessions(u: USERS)  2SESSIONS

32. SESSIONS The mapping of session s onto a set of roles SESSION ROLES
SQL
Admin
User
Guest
DB1.table1.session
session_roles(s:SESSION)2ROLE
session_role(s) ={ r∈ROLE: session_user(s)∈UA}

33. SESSIONS avail_session_perms(s) gives the set of permissions
Permissions available to a user in a session.
ROLE
PRMS
SESSION
SQL
DB1.table1.session
DB1.ADMIN
View
Update
Append
Create
Drop
avail_session_perms(s) gives the set of permissions
available to a user within a session
avail_session_perms(s) = ⋃ {assigened_perms(r) :
r ∈session_roles(s)}

34. Hierarchal RBAC (RH) Role Hierarchy (UA) User Assignment (PA)
Permission
Assignment
USERS
ROLES
OPS
OBS
PRMS
user_sessions
session_roles
SESSIONS
Hierarchal RBAC

35. Tree Hierarchies Tree Inverted Tree Production Engineer 1 Quality
Engineering Dept
Engineer 2
Tree
Inverted Tree
Production
Engineer 1
Project Lead 1
Quality
Director
Engineer 2
Project Lead 2

36. Lattice Hierarchy Production Engineer 1 Quality Engineering Dept
Project Lead 1
Director
Project Lead 2

37. RH (Role Hierarchies) < ⊆ ROLES x ROLES
Natural means of structuring roles to reflect organizational lines of authority and responsibilities
General and Limited
Define the inheritance relation among roles
i.e r1 inherits r2
Guest
-r-
User
r-w-h x
< ⊆ ROLES x ROLES

38. Authorized Users
Mapping of a role onto a set of users in the presence of a role hierarchy
First Tier USERS set
ROLE set
Admin.DB1
User.DB2
User.DB3
objects
User.DB1
User.DB1
View
Update
Append
User.DB2
permissions
authorized_users(r)= {u∈USRES : r’>r and (u,r’) ∈UA}

39. Authorized Permissions
Mapping of a role onto a set of permissions in the presence of a role hierarchy
PRMS set
ROLES set
View
Update
Append
Create
Drop
SQL
User.DB1
User.DB2
User.DB3
Admin.DB1
authorized_permissions: ROLE  2 PERMS
authorized_permissions(r)={p∈PERMS: r’>r and (p,r) ∈PA}

40. General RH r1 > r2  authorized_users(r2) ⊆ authorized_users(r1)
Guest Role Set
Support Multiple Inheritance
User Role Set
Power User Role Set
Admin Role Set
Only if all permissions of r1 are also permissions of r2
i.e r1 > r2
Only if all users of r1 are also users of r2
User
r-w-x
Guest
-r-
r1 > r2  authorized_users(r2) ⊆ authorized_users(r1)
r1 > r2  authorized_permissions(r2)
⊆ authorized_permissions(r1)

41. Limiting Inheritance ┓[ ∃ r ∈ ROLES r’ < r1 and r < r2 ]
Places restrictions on the immediate descendants of roles in a role hierarchy:
Example: No role can inherit from Role 1 and Role 2
Role 1
Role 2 may inherits
from Role 1
Role 3 does not
inherit from Role1
and Role 2
Role 2
Role 3
┓[ ∃ r ∈ ROLES r’ < r1 and r < r2 ]

42. Limiting the Role Hierarchy
Tom
AcctRec
AcctRecSpv
Accounting
Tammy
Cashier
CashierSpv
Fred
Sally
Auditing
Joe
Frank
Billing
BillingSpv
Curt
Tuan
Accounting Role
Frank has two roles: Billing and Cashier
This requires the union of two distinct roles and prevents Frank from being a node to others

43. Constrained RBAC user_sessions (RH) Role Hierarchy session_roles (UA)
User Assign-
ment
(PA)
Permission
Assignment
USERS
OBS
OPS
SESSIONS
ROLES
PRMS
SSD
DSD
Constrained RBAC

44. Separation of Duties
Enforces conflict of interest policies employed to prevent users from exceeding a reasonable level of authority for their position.
Ensures that failures of omission or commission within an organization can be caused only as a result of collusion among individuals.
Two Types:
Static Separation of Duties (SSoD)
Dynamic Separation of Duties (DSoD)

45. SSoD: Static Separation of Duty
SSoD places restrictions on the set of roles and in particular on their ability to form UA relations.
No user is assigned to n or more roles from the same role set, where n or more roles conflict with each other.
A user may be in one role, but not in another—mutually exclusive.
Example: Prevents a person from submitting and approving their own request for a pay hike.
Specification: SSoD(rSet: 2ROLES,n:Integer) satisfying the condition
∩{r⊆rSet and |r| > n}  authorized_users(r)=Ø

46. Properties of SSoD
A constraint on authorized users of the roles that have an SSD relation.
Based on authorized users rather than assigned users.
Ensures that inheritance does not undermine SSD policies.
Reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles.

47. DSoD: Dynamic Separation of Duty
Places constraints on the users that can be assigned to a set of roles, thereby reducing the number of potential permissions that can be made available to a user at any given time.
Constraints can be across or within a user’s session.
No user may activate n or more roles from the roles set in each user session.
Note: timely revocation of role assignment will ensures that permissions do not persist beyond the time that they are required for performance of duty.

48. Formalizing DSoD DSoD(rSet: 2ROLE,n:Integer)
∀ rSet ⊆ ROLE ∀n∈Integer ∀s ∈ Session ∀ rS ⊆ ROLE
n > 2 and DSoD(rSet,n), rS ⊆ rSet, rS ⊆ session_role(s)  |rS| < n
Says that every subset rS of the set of active roles in session s must have size < n.
Specifies session specific DSoD

49. DSoD Supervisor Roles Cashier Cashier Correct Error Supervisor
inherits
Cashier
Reduce
COI
Cashier
Correct Error
Supervisor
Closes Cashier Role session
Close Cash Drawer
Opens Supervisory Role session
Open Cash Drawer
Accounting Error

50. Role-Based Access Control
user_sessions
(RH)
Role Hierarchy
session_roles
(UA)
User Assign-
ment
(PA)
Permission
Assignment
USERS
OBS
OPS
SESSIONS
ROLES
PRMS
SSD
DSD

51. Specifying Pre and Post-Conditions
Consider an RBAC system with the following operations:
invokeRole(u:USER, s:Session, r:ROLE)
rescendRole(u:USER, s:Session, r:ROLE)
Maintain Tables (Predicates)
Users, Roles, Permissions, UA, PA, US, SR

52. Specifying Pre and Post-Conditions
Operations:
invokeRole(u:USER, s:Session, r:ROLE)
rescendRole(u:USER, s:Session, r:ROLE)
Maintain Tables (Predicates):
User(u), Roles(r), Perms(p), Session(s)
UA(u:USER, r:ROLE), PA(r:ROLE,p:Perms)
US(u:USER, s:Session), SR(s:Session,r:ROLE)
SSoD(rs:2ROLE,n:Int), DSoD(rs:2ROLE,n:Int)

53. Pre-Conditions for invokeRole
invokeRole(u:USER, s:Session, r:ROLE)
Steps:
Check if u, s, and r already exists u∈USER /\ s ∈ SESSION /\ r∈ROLE
Check if US(u,s): US(u,s)
Check static conditions:
UA(u,r) exists: UA(u,r)
Check if invoking r would violate DSoD
DSoD(rSet,n), rS ⊆ rSet, rS ⊆session_role(s)  |rS| < n

54. Post-Conditions for invokeRole
invokeRole(u:USER, s:Session, r:ROLE)
Steps:
Update US, SR:
SR’ = SR U {(s,r)}