1. Role-Based Access Control Standard
ANSI INCITS
James Joshi,
Associate Professor
University of Pittsburgh
Hi I am James Joshi, Associate Professor at the University of Pittsburgh, and welcome to this module on Role Based Access Control standard. The ANSI INCITS model. In this module we will overview the RBAC model and the various features it provides.

2. Access Control Access Control refers to
Ensuring principals are allowed or denied privileges to access resources
Basic Access Control Matrix model
Subjects: Active entities (rows)
E.g., user processes
Objects: Passive entities (columns)
E.g., files
Rights: refers to access mode
entries in each matrix cell representing what action a subject can perform on the corresponding object
Confidentiality
Authorized to read
We start with a quick overview of Access Control models. Access control refers to making sure an information system appropriately authorizes different principals or subjects to different protected resources.
There has been a lot of work in the area of Access control models. One of the very basic/generic access control model is the Access Control Matrix model – it defines a set of subjects which represent active entities that perform some operations (for instance, a subject maybe a user process in a system) , a set of objects that represent passive entities on which some actions maybe performed (for instance, files) and a set of rights that represent set of operations that are authorized for a subject over available objects. Access control models address the need for ensuring the confidentiality and integrity requirements of systems by restricting Read and Write or Modify privileges.
Integrity
Authorized to modify

3. Access Control Matrix
Here is an example of an access control matrix. The rows represent subjects and The columns represent objects. Each cell contains the rights that the corresponding subject has over the corresponding object. Given a system there might a huge matrix and many of the cells may be empty – and hence for actual implementation, one of the two approaches is often used. The first approach is the “Capabilities” based approach where one list is maintained for each subject as shown. In the ACL based approach, a separate list is maintained for each object.

4. Access Control Models Several models exist Some models
Discretionary Access Control (DAC) Model
Users can give rights to other users
Mandatory Access Control (MAC) model
System enforces mandatory rules
Some models
Bell LaPadula model Biba model of integrity
Clark-wilson model Chinese wall model
DAC is too flexible and MAC is often too restrictive
Researchers have looked for more flexible and more expressive models
RBAC has been considered a better
Various access control models have been proposed in the literature to capture the diverse requirements of different application domains. These traditional access control models can be categorized as Discretionary Access Control or DAC models and Mandatory Access Control or MAC models.
In a DAC model, a user typically has the discretionary power to share the rights that he has with other users. In a MAC model, however, a user does not have such a discretionary power – instead the rights and its use are controlled by system enforced rules.
Some models are as listed here.
In general, most of the traditional DAC models have been found to be too flexible and MAC models too restrictive. There has been a lot of efforts towards developing models that are flexible and expressive and can be generic enough to support different types of organizational access control policies. Role based access control has been found to be a promising approach in this direction.

5. RBAC: Role Based Access Control
Access control in organizations is based on “roles that individual users take on as part of the organization”
Access depends on function, not identity
Example:
Allison is bookkeeper for Math Dept. She has access to financial records.
She leaves and Betty is hired as bookkeeper The role of “bookkeeper” dictates access, not the identity of the individual.
A role is “is a collection of permissions”
The basic premise of the role-based access control approach is the fact that access privileges in an organization are typically distributed to users based on what roles they play in the organization. That is, access rights need to be authorized to users based on the functions that he needs to engaged in and not solely based on his identity.
For example, say Allison is a .. BK
Access
privileges

6. RBAC – two key advantages
Total number
Of assignments
n + m
n x m
Role
hierarchy

7. RBAC standard Standards efforts
Annual ACM RBAC Workshop – in 1990s
NIST Standard proposed in 2001 (TISSEC)
XACML Profile for RBAC
ANSI INCITS RBAC standard in 2004
The ANSI standard consists of two parts
Reference Model
System and Administrative Functional Specification

8. ANSI RBAC standard – Reference Model
Basic elements of the model
Users, Roles, Permissions, Relationships
Four model components
Core RBAC
Hierarchical RBAC
Static Separation of Duty RBAC
Dynamic Separation of Duty RBAC

9. Core RBAC Permissions UA PA Users Roles Operations Objects
user_sessions
(one-to-many)
role_sessions
(many-to-many)
Sessions

10. Core RBAC (relations) Permissions = 2Operations x Objects
UA ⊆ Users x Roles
PA ⊆ Permissions x Roles
assigned_users: Roles  2Users
assigned_permissions: Roles  2Permissions
Op(p): set of operations associated with permission p
Ob(p): set of objects associated with permission p
user_sessions: Users  2Sessions
session_user: Sessions  Users
session_roles: Sessions  2Roles
session_roles(s) =
{r | (session_user(s), r)  UA)}
avail_session_perms: Sessions  2Permissions

11. Hierarchical RBAC RH (role hierarchy) Permissions UA PA Users Roles
Operations
Objects
user_sessions
(one-to-many)
role_sessions
(many-to-many)
Sessions

12. Role Hierarchy General Role Hierarchy Limited Role hierarchy
Inheritance from multiple roles allowed
Limited Role hierarchy
No multiple inheritances
Single immediate descendant

13. General Role Hierarchy
A role can inherit from multiple roles
RH ⊆ Roles x Roles is a partial order
called the inheritance relation
written as ≥.
(r1 ≥ r2)  authorized_users(r1) ⊆ authorized_users(r2) &
authorized_permisssions(r2) ⊆ authorized_permisssions(r1)
authorized_users: Roles 2Users
authorized_users(r) = {u | r’ ≥ r &(r’, u)  UA}
authorized_permissions: Roles 2Permissions
authorized_permissions(r) = {p | r ≥ r’ &(p, r’) PA}

14. Limited Role Hierarchy
Imposes restriction on the immediate descendents of the general role hierarchy
That is, Limited role hierarchy is a General role hierarchy with the following limitation
 r, r1, r2 , r2  Roles, r ≥ r1  r ≥ r2  r1  r ≥ r2
In Limited Role hierarchy, a role can have only one descendent

15. Example authorized_users(Employee)? authorized_users(Administrator)?
authorized_permissions(Employee)?
authorized_permissions(Administrator)?
e10
e8, e9 e5 pp
e3, e4
e6, e7 po
pa, pb
e1, e2
px, py
pm, pn
p1, p2

16. Constrained RBAC: SSD RBAC & DSD RBACRH
(role hierarchy)
Static
Separation
of Duty
Permissions UA PA
Users
Roles
Operations
Objects
user_sessions
(one-to-many)
Dynamic
Separation
of Duty
Sessions

17. Separation of Duty SoD Security principle Example, Widely recognized
Captures conflict of interest policies to restrict authority of a single authority
Prevent Fraud
Example,
A single person should not be allowed to “approve a check” & “cash it”

18. Static Separation of Duty
Example: ({r1, r2}, 2) SSD
SSD ⊆2Roles x N
In absence of hierarchy
Collection of pairs (RS, n) where RS is a role set, n ≥ 2
for all (RS, n)  SSD, for all t ⊆RS:
|t| ≥ n  ∩rt assigned_users(r)= 
Example
Assume u1, u2, u3 are assigned to r1
Assume u2, u4 are assigned to r2
Is ({r1, r2}, 2)  SSD valid?

19. Static Separation of Duty
Example: ({r1, r2, r3}, 2) SSD
SSD ⊆2Roles x N
In presence of hierarchy
Collection of pairs (RS, n) where RS is a role set, n ≥ 2;
for all (RS, n)  SSD, for all t ⊆RS:
|t| ≥ n  ∩rt authorized_uers(r)= 
Example
Assume u1, u2, u3 are assigned to r1
Assume u4 are assigned to r2
Is ({r1, r2}, 2)  DSD valid?
What if u2 is assigned to r3 and r3 ≥ r2

20. Dynamic Separation of Duty
DSD ⊆2Roles x N
Collection of pairs (RS, n) where RS is a role set, n ≥ 2;
A user cannot activate n or more roles from RS
What is the difference between SSD or DSD containing:
(RS, n)?
Consider (RS, n) = ({r1, r2, r3}, 2)?
If SSD – can r1, r2 and r3 be assigned to u?
If DSD – can r1, r2 and r3 be assigned to u?

21. ANSI RBAC standard – Functional specification
Administrative operations
Creation and maintenance of sets and relations
Administrative review functions
To perform administrative queries
System level functionality
Creating and managing RBAC attributes on user sessions and making access decisions

22. Functional components for CORE RBAC
Administrative commands
AddUser Delete User
AddRole Delete Role
GrantPermissions RevokePermissions
AssignUser DeassignUser
CreateSession DeleteSession
AddActiveRole DropActiveRole
Supporting System functins
CreateSession, DeleteSession, AddActiveRole, DropActive Role, CheckAccess

23. Functional components for CORE RBAC
Review functions
AssignedUSers AssignedRoles
RolePermissions UserPermissions
SessionRoles SessionPermissions
RoleOperationsOnObject
UserOperationOnObject
For other RBAC
Extended/redefined set with regards to inheritance
Extended/redefined with regards to SSD/DSD

24. Functional Specification Package
Core
RBAC
Hierarchical RBAC
(a) General
(b) Limited
Methodology
for
Creating
functional
packages
SSD Relations
(a) w/Hierachy
(b)wo/Hierarchy
DSD Relations

25. Advantages of RBAC Allows Efficient Security Management
Administrative roles, Role hierarchy
Principle of least privilege allows minimizing damage
Separation of Duty constraints to prevent fraud
Allows grouping of objects / users
Policy-neutral - Provides generality
Encompasses DAC and MAC policies

26. RBAC’s Economic Benefits

27. Cost Benefits
Saves about 7.01 minutes per employee, per year in administrative functions
Assume Average IT admin salary - $59.27 per hour
The annual cost saving is:
$6,924/1000;
$692,471/100,000

28. Quantified Economic Benefits
NIST did an economic benefit survey analysis in 2009
More efficient provisioning by network and systems administrators,
Reduced employee downtime from more efficient provisioning, and
More efficient access control policy maintenance and certification

29. Quantified Economic Benefits
Quantified economic benefits of RBAC for adopting firms, per employee
From NIST Report: 2010 Economic Analysis of Role-Based Access Control

30. RBAC Extensions
Several Extensions have been made to make RBAC applicable to different application scenarios
TRBAC/GTRBAC (time based RBAC0
LoT/Geo RBAC (Location based)
GeoSocial RBAC
Privacy aware RBAC
Etc.

31. Summary Overview of ANSI RBAC standard Four component models
Functional Specification
Advantages and Economic benefits