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 – Now official standard – approved on Feb

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

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.

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.

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.

RBAC Framework model RBAC Framework model components –Core RBAC introduces the concept of role activation as part of a user’s session within a computer system. required in any RBAC system, but the other components are independent of each other and may be implemented separately. –Hierarchical RBAC relations for supporting role hierarchies (inheritance among roles) –Static Separation of Duty Relations adds exclusivity relations among roles w.r.t. user assignments potential for inconsistencies w.r.t. static separation of duty relations and inheritance relations of a role hierarchy defines relations in both the presence and absence of role hierarchies. – Dynamic Separation of Duty Relations exclusivity relations w.r.t. roles that are activated as part of a user’s session.

Role-Based Access Control USERSROLES SESSIONS OPSOBS PRMS session_rolesuser_session User Assignment (UA) Permission Assignment (PA) many-to-many relationship one-to-many relationship Gives roles activated by the session User is associated with a session file system operations: read, write and execute DBMS operations: Insert, delete, append and update

Hierarchical RBAC USERSROLES SESSIONS OPSOBS PRMS session_rolesuser_session User Assignment (UA) Permission Assignment (PA) Role Hierarchy (RH) Role Hierarchy defines the Inheritance relationship among roles. Role of Specialist could contain the roles of Doctor and Intern. members of the role Specialist are implicitly associated with the operations associated with the roles Doctor and Intern without the administrator having to explicitly list the Doctor and Intern operations. Moreover, the roles Cardiologist and Rheumatologist could each contain the Specialist role.

Hierarchal RBAC Role hierarchies –General role hierarchies Include the concept of multiple inheritance of permissions and user membership among roles –Limited role hierarchies Impose restrictions Role may have one or more immediate ascendants, but is restricted to a single immediate descendent

Conflict of Interest Static Separation of Duty: user cannot be authorized for both roles, e.g., teller and auditor –SSoD policies deter fraud by placing constrains on administrative actions and thereby restricting combinations of privileges that are made available to users Dynamic Separation of Duty: user cannot act simultaneously in both roles, e.g., teller and account holder –DSoD policies deter fraud by placing constrains on the roles that can be activated in any given session thereby restricting combinations of privileges that are made available to user

Static Separation of Duty SSD relations –prevent conflict of interests that arise when a user gains permissions associated with conflicting roles –SSD relations are specified for any pair of roles that conflict. A bank defines teller role as being able to perform a savings deposit operation. requires read and write access to specific fields within a savings file. accounting supervisor role is allowed to perform correction operations. operations require read and write access to the same fields of a savings file as the teller. The accounting supervisor may not be allowed to initiate deposits or withdrawals but only perform corrections. The teller is not allowed to perform any corrections once the transaction has been completed.

SSD with Hierarchical RBAC USERSROLES SESSIONS OPSOBS PRMS session_rolesuser_session User Assignment (UA) Permission Assignment (PA) Role Hierarchy (RH) SSD

DSD example A user may be authorized for both the roles of Cashier and Cashier Supervisor, where the supervisor is allowed to acknowledge corrections to a Cashier’s open cash drawer. If the individual acting in the role Cashier attempted to switch to the role Cashier Supervisor, RBAC would require the user to drop the Cashier role, and thereby force the closure of the cash drawer before assuming the role Cashier Supervisor. As long as the same user is not allowed to assume both of these roles at the same time, a conflict of interest situation will not arise. this can be achieved through the establishment of a static separation of duty relationship, DSD relationships generally provide the enterprise with greater operational flexibility.

Dynamic Separation of Duty 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 USERSROLES SESSIONS OPSOBS PRMS session_rolesuser_session User Assignment (UA) Permission Assignment (PA) Role Hierarchy (RH) DSD

Questions ?

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