Role Based Access control By Ganesh Godavari

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

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

Where is RBAC used RBAC is currently used in –Database management systems –Security management and network operating system !! Solaris 8 !! Uses RBAC –

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.

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

Access Controls Types Discretionary Access Control Mandatory Access Control Role-Based Access Control

Discretionary AC Name Access Tom Yes John No Cindy Yes Application Access List 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 Legacy Apps

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. Better security than DAC Principle: Read Down Access equal or less Clearance Write Up Access equal or higher Clearance

Mandatory AC (cont) Individuals Resources Server 1 “Top Secret” Server 3 “Classified” Server 2 “Secret” Legacy Apps

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.

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

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.

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

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

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

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.

Role-Based Access Control user_sessions(RH) Role Hierarchy session_roles (UA) User Assign- ment (PA) Permission Assignment USERSOBSOPS SESSIONS ROLES PRMS SSD DSD

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.

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

References Role Based Access Control– Draft & Presentation on RBAC standard by Wilfredo Alvarez available at Modeling Role-Based Access Control Using Parameterized UML Models -- Dae-Kyoo Kim, Indrakshi Ray, Robert France, Na Li