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– http://www.securityfocus.com/infocus/1391

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 AccessTom YesJohn NoCindy Yes

ApplicationAccess 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 2Legacy 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 Roles Resources

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

notesStatic Separation of Duty (SSD) relations are necessary to prevent conflict of intereststhat arise when a user gains permissions associated with conflicting roles (rolesthat cannot be assigned to the same user). SSD relations are specified for any pair ofroles that conflict. The SSD relation places a constraint on the assignment of users toroles, that is, assignment to a role that takes part in an SSD relation prevents the userfrom 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 aswell. The DSD relations place constraints on the roles that can be activated in a user’ssession. If one role that takes part in a DSD relation is activated, the user cannot activatethe related (conflicting) role in the same session.

Role-Based Access Control

user_sessions

(RH)Role Hierarchy

session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PRMS

SSD

DSD

notesFigure back consists of: 1) a set of users (USERS) where a user is an intelligentautonomous agent, 2) a set of roles (ROLES) where a role is a job function, 3) a setof objects (OBS) where an object is an entity that contains or receives information, 4) aset 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 operationon objects.

The cardinalities of the relationships are indicated by the absence (denotingone) or presence of arrows (denoting many) on the corresponding associations. Forexample, the association of user to session is one-to-many. All other associations shownin the figure are many-to-many. The association labeled Role Hierarchy defines theInheritance relationship among roles. The association labeled SSD specifies the rolesThat conflict with each other. The association labeled DSD specifies the roles that cannotBe 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 http://csrc.nist.gov/rbac/

• Modeling Role-Based Access Control Using Parameterized UML Models -- Dae-Kyoo Kim, Indrakshi Ray, Robert France, Na Li