Role Based Access control

1. Role Based Access control By Ganesh Godavari

2. Outline of the talk • Motivation • Terms and Definitions • Current Access Control Mechanism • Role Based Access Control • What are the RABC Core Component

3. Motivation • Information Sharing needs access control. • Can RBAC provide access control Information sharing?

4. Where is RBAC used • RBAC is currently used in • Database management systems • Security management and network operating system • !! Solaris 8 !! Uses RBAC • http://www.securityfocus.com/infocus/1391

5. Terms and Definitions • Component – refers to one of the major blocks of RBAC features, core RBAC, hierarchical RBAC, Static Separation of Duty (SSD) relations, and Dynamic Separation of Duty (DSD) relations. • Objects – object can be any system resource subject to access control, such as a file, printer, terminal, database record, etc. • Operations - An operation is an executable image of a program, which upon invocation executes some function for the user. • Permissions - Permission is an approval to perform an operation on one or more RBAC protected objects. • Role - A role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role. • User - A user is defined as a human being. Although the concept of a user can be extended to include machines, networks, or intelligent autonomous agents, the definition is limited to a person in this document for simplicity reasons.

6. Think about this… • “Although the fundamental concepts of roles are common knowledge, the capability to formalize model specifications needed to implement RBAC models is beyond the knowledge base of existing staff in many software companies” • “The lack of knowledge and staff expertise in the area of RBAC increases the uncertainty of both the technical feasibility of developing successful RBAC-enabled products and the development cost and time frame.” -The Economic Impact of Role-Based Access Control The Time is NOW!

7. Access Controls Types • Discretionary Access Control • Mandatory Access Control • Role-Based Access Control

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

9. 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 Better security than DAC

10. Mandatory AC (cont) LegacyApps Individuals Resources Server 1 “Top Secret” Server 2 “Secret” Server 3 “Classified”

11. 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 job authority and responsibilities within a job function. • Operations on an object are invocated based on the permissions. • The object is concerned with the user’s role and not the user.

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

13. Privilege • Roles are engineered based on the principle of least privileged . • A role contains the minimum amount of permissions to instantiate an object. • A user is assigned to a role that allows him or her to perform only what’s required for that role. • No single role is given more permission than the same role for another user.

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

15. Core Components • Defines: • USERS • ROLES • OPERATIONS (ops) • OBJECTS (obs) • User Assignments (ua) • assigned_users

16. notes Core RABC Requires that users be assigned to roles (job functions), roles be assigned with permissions (approval to perform an operation on an object) and users acquire permissions by being assigned to roles. A user establishes a session during which he activates a subset of roles assigned to him. Each user can activate multiple sessions; however each session is associated with only one user. The operation that a user can perform in a session depends on the roles activated in that session and permissions associated with those roles

17. notes Static Separation of Duty (SSD) relations are necessary to prevent conflict of interests that arise when a user gains permissions associated with conflicting roles (roles that cannot be assigned to the same user). SSD relations are specified for any pair of roles that conflict. The SSD relation places a constraint on the assignment of users to roles, that is, assignment to a role that takes part in an SSD relation prevents the user from being assigned to the related conflicting role. The SSD relationship is symmetric, but it is neither reflexive nor transitive. SSD may exist in the absence of role hierarchies (referred to as SSD RBAC), or in the presence of role hierarchies (referred to as hierarchical SSD RBAC). The presence of role hierarchies complicates the enforcement of the SSD relations: before assigning users to roles not only should one check the direct user assignments but also the indirect user assignments that occur due to the presence of the role hierarchies. Dynamic Separation of Duty (DSD) relations aim to prevent conflict of interests as well. The DSD relations place constraints on the roles that can be activated in a user’s session. If one role that takes part in a DSD relation is activated, the user cannot activate the related (conflicting) role in the same session.

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

19. notes Figure back consists of: 1) a set of users (USERS) where a user is an intelligent autonomous agent, 2) a set of roles (ROLES) where a role is a job function, 3) a set of objects (OBS) where an object is an entity that contains or receives information, 4) a set of operations (OPS) where an operation is an executable image of a program, and 5) a set of permissions (PRMS) where a permission is an approval to perform an operation on objects. The cardinalities of the relationships are indicated by the absence (denoting one) or presence of arrows (denoting many) on the corresponding associations. For example, the association of user to session is one-to-many. All other associations shown in the figure are many-to-many. The association labeled Role Hierarchy defines the Inheritance relationship among roles. The association labeled SSD specifies the roles That conflict with each other. The association labeled DSD specifies the roles that cannot Be activated within a session by the same user.

20. Work to be done • Modify SGFR client for file transfer – client transfers file to a central server and the from where the file is sent through multicast to various group members

21. References • Role Based Access Control– Draft & Presentation on RBAC standard by Wilfredo Alvarez available at http://csrc.nist.gov/rbac/ • Modeling Role-Based Access Control Using Parameterized UML Models -- Dae-Kyoo Kim, Indrakshi Ray, Robert France, Na Li