1. RBACRole-Based Access Control

2. RBAC: “?” • Aim:- A framework which simplifies management of permissions by associating permissions with roles, and users with appropriate roles. • Roles can be granted new permissions as new applications and systems are incorporated, and permissions can be revoked from roles as needed. • The role is more stable because an organization’s activities or functions usually change less frequently in contrast to the users’ membership to roles. Vishwas Patil, TIFR.

3. RBAC: Principles • RBAC is policy-neutral by itself. Vishwas Patil, TIFR.

4. RBAC: Family • RBAC0 is the base model. • RBAC1adds the concept of role hierarchies. • RBAC2adds constraints. • RBAC3 = RBAC1 + RBAC2 Role Hierarchy (RH) users (U) roles (R) permiss- ions (P) Permission Assignment (PA) User Assignment (UA) Vishwas Patil, TIFR.

5. user: human being / autonomous agent / computer • role: job function with associated semantics regarding the authority and responsibility conferred on a member of the role. • permission: an approval of a particular mode of access to one or more objects in the system. • user assignment: many-to-many relation between U and R. • permission assignment: many-to-many relation between R and P. • session (S): mapping of one user to possibly many roles. Vishwas Patil, TIFR.

6. RBAC0 • PA  P x R • UA  U x R • user : S  U, a function mapping each session si to the single user user(si) (constant for the session’s lifetime) • roles : S  2R, a function mapping each session si to a set of roles roles(si) {r | (user(si),r)  UA} (which can change with time) and session si has the permissions rroles(si){p | (p,r)  PA}. Vishwas Patil, TIFR.

7. RBAC1 • U, R, P, S, PA, UA, and user are unchanged from RBAC0 • RH  R x R is a partial order on R called the role hierarchy relation, written as  • roles : S  2R is modified from RBAC0 to require a roles(si) {r | (r'  r)[(user(si), r' )  UA]} (which can change with time) and session si has the permissions rroles(si){p | (r'' r)[(p, r'')  PA]}. Vishwas Patil, TIFR.

8. RBAC2 • RBAC2 is unchanged from RBAC0 except for requiring that there be a collection of constraints that determine whether or not values of various components of RBAC0 are acceptable. • Only acceptable values will be permitted. • Ex. mutually exclusive roles, prerequisite roles • A role hierarchy can be considered as a constraint! Vishwas Patil, TIFR.

9. RBAC3 • RBAC3 combines RBAC1 and RBAC2 to provide both role hierarchies and constraints. Vishwas Patil, TIFR.

10. RBAC: Discussion • e-CRM applications, ORACLE, Operating Systems • Other advantages/disadvantages • NIST standards • Scalability, manageability issues Vishwas Patil, TIFR.