1

ROLE BASED ACCESS CONTROL

Group 4 :

Lê Quốc Thanh

Trần Việt Tuấn Anh

2

1) Introduction

2) Background

3) RBAC Reference Model

4) Components of RBAC Core RBAC Hierarchical RBAC Static Separation of Duty Relations Dynamic Separation of Duty Relations

5) Advantages and Disadvantages of RBAC

6) Demo

OUTLINE

3

INTRODUCTION

- Role base access control :

is an access policy determined by the system, not by the owner

uses a centrally set of controls to determine how users and objects interact to each other.

- The main point of RBAC is that permissions are associated with roles, and users are assigned to appropriate roles

4

BACKGROUND• Terms Definition:

Roles are defined based on job functions and can be viewed as a set of permissions.

Permissions are defined based on authorities and responsibilities of a job.

Operations on an object are invocated based on the permissions.

Objects can be any system resources such as a files, database record, etc.

Users have access to an object based on the assigned role and can be easily reassigned

from one role to another.

• RBAC differs from DAC in that DAC allows users to control access to their resources directly,

while in RBAC, access is controlled at the system level, outside of the user's control.

5

BACKGROUND (count)• Non-role-based systems

• Role-Based Access Control Systems (RBAC)

Alice Bob Carl Dave Eva

Windows

Account

Linux

Account

Web service

Account

Oracle

Account

Users:

Objects:

Alice Bob Carl Dave Eva

Windows

Account

Linux

Account

Web service

Account

Oracle

Account

DB Admin Web Admin Software Developer

Users:

Roles:

Objects:

6

RBAC REFERENCE MODEL The RBAC model is defined in terms of four model components:

• Core RBAC

• Hierarchical RBAC

• Static Separation of Duty Relations

• Dynamic Separation of Duty Relations

Each component is defined by subcomponents:

• Set of basic elements sets

• A set of RBAC relations involving those elements sets.

• A set of mapping functions that yield instances of members from one

element set for a given instance from another element set.

7

COMPONENTS OF RBAC1) Core RBAC

- Core RBAC:

• defines a minimum collection of RBAC elements, element sets, and relations in order to completely

achieve a Role-Based Access Control system. This includes user-role assignment and permission-role

assignment relations, considered fundamental in any RBAC system.

• is required in any RBAC system, but the other components are independent of each other

and may be implemented separately.

• defines basic functionality, any implementation of the RBAC standard has to follow:

Creating and deleting users, roles and sessions

Creating and deleting permissions on resources

8

COMPONENTS OF RBAC1) Core RBAC

Many-to-many relationship among individual users and roles

Session is a mapping between a user and an activated subset of assigned roles

user_sessions session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBJECTSOPERATIONS

SESSIONS

ROLES

PERMISSIONS

one-to-many relationship

many-to-many relationship

9

COMPONENTS OF RBAC2) Hierarchical RBAC

• Hierarchical RBAC:

is mathematically a partial order defining a inheritance relations between roles

adds relations for supporting role hierarchies.

• Two types of role hierarchies

General Hierarchical: support for an arbitrary partial order to serve as role hierarchy, to include the concept

of multiple inheritance of permissions and user membership among roles.

Limited Hierarchical: impose restrictions resulting in a simpler tree structure

10

COMPONENTS OF RBAC2) Hierarchical RBAC

• Role hierarchies define an inheritance relation among roles

• Two types of hierarchies:

- Limited hierarchies

- General hierarchies

user_sessions

(RH)Role Hierarchy

(UA)User Assignment

(PA)PermissionAssignment

USERS OBJECTSOPERATIONS

SESSIONS

ROLES

PERMISSIONS

11

COMPONENTS OF RBAC3) Static Separation of Duty Relations

Static Separation of Duty Relations (SSD) :

Sets define two or more roles that cannot be assigned to the same user at any time

These restrictions are checked each time a user is assigned to a role

SSD relations define and place constraints on a user’s total permission space

SSD relations may exist within hierarchical RBAC

12

COMPONENTS OF RBAC3) Static Separation of Duty Relations

SSD relations place constraints on the assignments of users to roles. Membership in one role may prevent the user from being a member of one or more other roles, depending on the SSD rules enforced.

user_sessions

(RH)Role Hierarchy

(UA)User Assignment

(PA)PermissionAssignment

USERS OBJECTSOPERATIONS

SESSIONS

ROLES

PERMISSIONS

STATIC SEPARATION OF DUTY

13

COMPONENTS OF RBAC4) Dynamic Separation of Duty Relations

Dynamic separation of duty (DSD):

Restrictions are only checked when activating a role for a user's session

Active roles are assigned to a user's session

Users are allowed to be assigned to roles that exclude on another but they are not allowed to activate them

at the same time

14

COMPONENTS OF RBAC4) Dynamic Separation of Duty Relations

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 role in the same session (conflicting)

user_sessions

(RH)Role Hierarchy

session_roles

(UA)User Assignment

(PA)PermissionAssignment

USERS OBJECTSOPERATIONS

SESSIONS

ROLES

PERMISSIONS

DYNAMIC SEPARATION OF DUTY

15

ADVANTAGES OF RBAC

Easy to enforce enterprise-specific security policies

Security management is simplified

Reduce administrative costs

Ensure system integrity and availability by explicitly controlling not only which resources can be

accessed but also how access can occur

16

DISADVANTAGES OF RBAC

Unsupported for applications where a user can have many complex

roles

In large systems, memberships, role inheritance, and the need for

customized privileges make administration potentially unwieldy

17

REFERENCES

Ravi S. Sandhu “ Role-Based Access Control ”

Gail - Joon Ahn and Ravi Sandhu “Role-Based Authorization Constraints Specification”

Sandhu R. et. al. “Role-based Access Control Models”. IEEE Computer, 29(2):38-47 February 1996

Sandhu R. “Issues in RBAC”, 1st Workshop on Role-based Access Control, pp. 21-24, 1995.

Sandhu R., Ferraiolo D. and Kuhn R. “The NIST Model for Role-Based Access Control”

18

DEMO

SAP ERP 6.0 concepts

• Transaction code (Tcode): Program to be executed (SU01, SU53, PFCG)

• Single Role

• Composite Role Create 1 User (DEMO) and 2 Role (Z_ROLE_DEMO & Z_ROLE_DEMO1) Assign Z_ROLE_DEMO to user Trying another Tcode which is not in Z_ROLE_DEMO

19

Thanks for listening