1. Information Security CS 526
Topic 22: Role and Attribute Based Access Control
CS526
Topic 22: RBAC

2. Readings for This Lecture
RBAC96 Family
R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman. “Role-Based Access Control Models”. IEEE Computer, 29(2):38--47, February 1996.
CS526
Topic 22: RBAC

3. Background: Role Based Access Control
Non-role-based systems
Role-Based Access Control Systems (RBAC)
Alice
Bob
Carl
Dave
Eva
Users:
DB2 Account
WebSphere Account
Windows Account
Linux Account
Permissions:
Alice
Bob
Carl
Dave
Eva
Users:
As opposed to identity-based access control, label-based access control.
DB Admin
Web Admin
Software Developer
Roles:
DB2 Account
WebSphere Account
Windows Account
Linux Account
Permissions:
CS526
Topic 22: RBAC

4. ROLE-BASED ACCESS CONTROL (RBAC)
Motivating Problem: how to administer user-permission relation
Different from DAC and MAC, which deal with processes in operating systems
Roles as a level of indirection
Butler Lampson or David Wheeler: "all problems in Computer Science can be solved by another level of indirection"
RBAC is multi-faceted and open ended
Extensions: ARBAC (administrative), CBRAC (constraint), dRBAC (dynamic), ERBAC (enterprise), fRBAC (flexible), GRBAC (generalized), HRBAC (hierarchical), IRBAC (interoperability), JRBAC (Java), LRBAC (Location), MRBAC (Management), PRBAC (privacy), QRBAC (QoS), RRBAC(Rule), SRBAC(Spatial), TRBAC (temporal), V, W, x.
Butler Lampson is often quoted, but he attributed it to David Wheeler in his Turing Award lecture. David Wheeler is the first PhD in Computer Science in 1951.
What is the problem RBAC intends to solve?
A user’s permissions are determined by the user’s roles
rather than identity or clearance
roles can encode arbitrary attributes
CS526
Topic 22: RBAC

5. Why Roles? Fewer relationships to manage
possibly from O(mn) to O(m+n), where m is the number of users and n is the number of permissions
Organizations operate based on roles
A role may be more stable than
the collection of users and the collection of permissions that are associated with it
Revocation/change of permissions become easier
Can solve the problem of assigning permissions to users in a more principled way. See what job functionalities a user needs to perform, and then what permissions are needed for the functionalities.
A role brings together
a collection of users and
a collection of permissions
These collections will vary over time
A role has significance and meaning beyond the particular users and permissions brought together at any moment
CS526
Topic 22: RBAC

6. Groups vs. Roles
Some differences that may or may not be important, depending on the situation
Answer 1: sets of users vs. sets of users as well as permissions
Answer 2: roles can be activated and deactivated, groups cannot
Groups can be used to prevent access with negative authorization.
Roles can be deactivated for least privilege
Answer 3: can easily enumerate permissions that a role has, but not for groups
Depending on the precise definitions of them, can be the same or different.
Conceptually, the user-group relation is more stable than group-permission. The role-permission relation is more stable than user-role.
CS526
Topic 22: RBAC

7. RBAC96 FAMILY OF MODELS (Sandhu et al.)
ROLE HIERARCHIES +
CONSTRAINTS
RBAC1
ROLE
HIERARCHIES
RBAC2
CONSTRAINTS
Cited more than 4000 times according to Google scholar in November 2010.
RBAC0
BASIC RBAC
CS526
Topic 22: RBAC

8. RBAC0 ... ROLES USER-ROLE ASSIGNMENT PERMISSION-ROLE USERS PERMISSIONS
SESSIONS
Four sets.
Four relations: two are many to many.
One is one to one. One is one to many.
This is a somewhat busy slide
It shows a bird’s eye view of RBAC
There are many details that need to be debated and filled in
Some of these will be discussed in the subsequent panel
For our purpose the bird’s eye view will suffice
CS526
Topic 22: RBAC

9. PERMISSIONS Left abstract in the RBAC96 model Permissions are positive
No negative permissions or denials
RBAC defines a closed policy, i.e., all accesses are denied unless they are explicitly authorized
No duties or obligations
Example obligation: can access patient document, but must notify patient, or must delete after 30 days
negative permissions and denials can be handled by constraints
RBAC should be a flexible concept that can accommodate all of these
CS526
Topic 22: RBAC

10. RBAC0: Formal Model Static relations: Dynamic relations:
Vocabulary: U, R, P, S (users, roles, permissions, and sessions)
Static relations:
PA  P × R (permission assignment)
UA  U × R (user assignment)
Dynamic relations:
user: S  U each session has one user
roles: S  2R and some activated roles
requires roles(s)  { r | (user(s), r)  UA }
PA and UA are n-to-n relation.
Can be represented as three layers: users, roles, permissions
each session has only one user
session and role n-to-n relation
Session s has permissions  r  roles(s) { p | (p, r)  PA }
CS526
Topic 22: RBAC

11. RBAC1 ... ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSION-ROLE
USERS
ROLES
PERMISSIONS
...
SESSIONS
This is a somewhat busy slide
It shows a bird’s eye view of RBAC
There are many details that need to be debated and filled in
Some of these will be discussed in the subsequent panel
For our purpose the bird’s eye view will suffice
CS526
Topic 22: RBAC

12. HIERARCHICAL ROLES (ex 1)
Primary-Care
Physician
Specialist
Physician
Physician
More senior/junior role. A partial order.
Health-Care Provider
CS526
Topic 22: RBAC

13. HIERARCHICAL ROLES (ex 2)
Engineer
Hardware
Software
Supervising
CS526
Topic 22: RBAC

14. Semantics of Role Hierarchies
User inheritance
r1r2 means every user that is a member of r1 is also a member of r2
Permission inheritance
r1r2 means every permission that is authorized for r2 is also authorized r1
Activation inheritance
r1r2 means that activating r1 will also activate r2
Physician
Health-Care Provider
Permission and Activation inheritance have different effect when there are constraints about activation.
CS526
Topic 22: RBAC

15. RBAC1: Formal Model U, R, P, S, PA, UA, and user unchanged from RBAC0
RH  R × R : a partial order on R, written as 
When r1  r2, we say r1 is a senior than r2, and r2 is a junior than r1
roles: S  2R
requires roles(s)  { r |  r’ [(r’  r) & (user(s), r’)  UA] }
Session s includes permissions  r  roles(s) { p |  r’’ [(r  r’’) & (p, r’’)  PA] }
CS526
Topic 22: RBAC

16. RBAC2: RBAC0 + Constraints
No formal model specified
Example constraints
Mutual exclusion
Pre-condition: Must satisfy some condition to be member of some role
E.g., a user must be an undergrad student before being assigned the UTA role
Cardinality
CS526
Topic 22: RBAC

17. Mutual Exclusion Constraints
Mutually Exclusive Roles
Static Exclusion: No user can hold both roles
often referred to as Static Separation of Duty constraints
Preventing a single user from having too much permissions
Dynamic Exclusion: No user can activate both roles in one session
Often referred to as Dynamic Separation of Duty constraints
Interact with role hierarchy interpretation
Relation of static exclusion with separation of duty
Example of Dynamic Exclusion: Think of grocery shopping. Two roles: customer and cashier. Cashier can also buy stuff.
CS526
Topic 22: RBAC

18. Cardinality Constraints
On User-Role Assignment
at most k users can belong to the role
at least k users must belong to the role
exactly k users must belong to the role
On activation
at most k users can activate a role …
CS526
Topic 22: RBAC

19. Why Using Constraints? For laying out higher level organization policy
Only a tool for convenience and error checking when admin is centralized
Not absolutely necessary if admin is always vigilant, as admin can check all organization policies are met when making any changes to RBAC policies
Like “assert” statements in C/C++/Java programs
A tool to enforce high-level policies when admin is decentralized
For centralized admin, reduce the chance of mistake.
A constraint that no user can be assigned two roles can be implicitly enforced without specifying the constraint.
CS526
Topic 22: RBAC

20. RBAC3 ... ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE
USERS
ROLES
PERMISSIONS
...
SESSIONS
CONSTRAINTS
This is a somewhat busy slide
It shows a bird’s eye view of RBAC
There are many details that need to be debated and filled in
Some of these will be discussed in the subsequent panel
For our purpose the bird’s eye view will suffice
CS526
Topic 22: RBAC

21. Products Using RBAC Data Base Management Systems (DBMS)
Enterprise Security Management
IBM Tivoli Identity Manager (central administration and provisioning of accounts, resources, etc)
Many operating systems claim to use roles
Though only in very limited way
CS526
Topic 22: RBAC

22. The NIST Standard
Proposed NIST Standard for Role-Based Access Control. David F. Ferraiolo, Ravi S. Sandhu, Serban I. Gavrila, D. Richard Kuhn, and Ramaswamy Chandramouli. TISSEC, August 2001.
American National Standards Institute Standard, 2004
Has a number of flaws, including with typos, errors in math definitions, and others high-level design choices
CS526
Topic 22: RBAC

23. Overview of the NIST Standard for RBAC
Static Separation of Duties
Dynamic Separation of Duties
Hierarchical RBAC
Core RBAC
CS526
Topic 22: RBAC

24. Research Challenges in RBAC
Role engineering
Design roles for an access control scenario.
Top down approach: start from analyzing business requirement.
Bottom up approach: Role Mining: mine existing access control data for roles
Effective administration of RBAC systems
Especially help ensure updates still lead to useful states
Effective usage of constraints
CS526
Topic 22: RBAC

25. Attribute-Based Access Control
An access control method where subject requests to perform operations on objects are granted or denied based on
assigned attributes of the subject,
E.g., job role, clearance, division/unit, location
assigned attributes of the object,
E.g.,
environment conditions,
E.g., time, state of emergency
and a set of policies that are specified in terms of those attributes and conditions.
E.g., a list of rules, as in firewall policies,
CS526
Topic 22: RBAC

26. Coming Attractions …
Network Security
CS526
Topic 22: RBAC