NETWORK SECURITY & MANAGEMENT

Role Based Access Control

Presented by Mir Tahmid Hossain

ROLE BASED ACCESS CONTROL

A rich and open-ended technology which is evolving as users, researchers and vendors gain experience with it and is used in different ways by different vendors and users. A proven technology for large-scale authorization.

The NIST model seeks to resolve this situation by unifying ideas from prior RBAC models, commercial products and research prototypes.

ROLE BASED ACCESS CONTROL

Features: A valuable level of abstraction to promote security to promote security administration at a business enterprise level rather than at the user identity level. A powerful mechanism for reducing the complexity , cost and potential for error in assigning user permissions within the enterprise. To establish roll hierarchies where a given role can include all permissions of another role.


ROLE BASED ACCESS CONTROL

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 users role and not the user.

ROLE BASED ACCESS CONTROL

Individuals Rolls Resources

Role 1

Server 1

Role 2

Server 2

Server 3 Role 3

Users change frequently, Roles dont

RABC MODEL OVERVIEW

file system operations: read, write and execute
SSD (RH) Role Hierarchy

DBMS operations: Insert, delete, append and update

(PA) Permission Assignment

(UA) User Assignment

USERS

ROLES

OPS

OBS

PRMS user_sessions session_roles

Gives roles activated by the session

SESSIONS DSD

User is associated with a session

many-to-many relationship one-to-many relationship

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

ROLE BASED ACCESS CONTROL

The NIST model is organized into four levels of increasing functional capabilities . These levels are cumulative in that each includes the requirements of the previous ones in the sequence.

Flat RBAC Hierarchical RBAC Constrained RBAC Symmetric RBAC

FLAT RBAC
 LEVEL 1

Is that users are assigned to roles, permissions are assigned to roles and users acquire permissions by being members of roles. The NIST RBAC model requires that user-role and permissionrole assignment can be many-to-many.

(UA) User Assignment USERS ROLES

(PA) Permission Assignment

P PERMISSIONS

Flat RBAC has a requirement to a specific user can be determined as well as users assigned to a specific role.

FLAT RBAC


Functional Capabilities:

Users acquire permissions through roles Must support many-to-many user-role assignment Must support many-to-many permission-role assignment Must support user-role assignment review Users can use permissions of multiple roles simultaneously

Level 2
SSD

HIERARCHICAL RBAC
(RH) Role Hierarchy (UA) User Assignment USERS ROLES (PA) Permission Assignment

P PERMISSIO NS

Adds a requirement for supporting role hierarchies The NIST model recognizes two hierarchies: Role hierarchies

General role hierarchies

Include the concept of multiple inheritance of permissions and user membership among role

Limited role hierarchies

Impose restrictions Role may have one or more immediate ascendants, but is restricted to a single immediate descendent Separation of Duty Relations Static Dynamic

TREE HIERARCHIES
Production Engineer 1 Engineer 1 Quality Engineer 1 Production Engineer 2 Engineer 2 Quality Engineer 2

Engineering Dept

Director

Project Lead 1

Project Lead 2

Production Engineer 1

Quality Engineer 1

Production Engineer 2

Quality Engineer 2

GENERAL HIERARCHY
Director

Project Lead 1

Project Lead 2

Production Engineer 1

Quality Engineer 1

Production Engineer 2

Quality Engineer 2

Engineer 1

Engineer 2

Engineering Dept

LIMITED RH

A restriction on the immediate descendants of the general role hierarchy.

Role2 Role2 inherits from Role1 Role3 Role1 Role3 does not inherit from Role1 or Role2

LIMITED RH
Fred Curt Tuan

Tom

AcctRecSpv

Sally

Joe

Tammy

CashierSpv

Frank

BillingSpv

AcctRec

Auditing

Cashier

Billing

Accounting

Accounting Role Notice that Frank has two roles: Billing and Cashier This requires the union of two distinct roles and prevents Frank from being a node to others

CONSTRAINED RBAC
Level 3
SSD (UA) User Assignment USERS ROLES (RH) Role Hierarchy (PA) Permission Assignment

P PERMIS SIONS

Constrained RBAC - SOD

SSD (RH) Role Hierarchy (UA) User Assignment USERS ROLES (PA) Permission Assignment

P PERMISSIONS

user_sessions SESSIONS .

. .

Roles

SEPARATION OF DUTIES
Enforces conflict of interest policies employed to prevent users from exceeding a reasonable level of authority for their position. Ensures that failures of omission or commission within an organization can be caused only as a result of collusion among individuals. Two Types:

Static Separation of Duties (SSD) y Dynamic Separation of Duties (DSD)

y

SSD

SSD places restrictions on the set of roles and in particular on their ability to form UA relations. No user is assigned to n or more roles from the same role set, where n or more roles conflict with each other. A user may be in one role, but not in another mutually exclusive. Prevents a person from submitting and approving their own request.

DSD

Places constraints on the users that can be assigned to a set of roles, thereby reducing the number of potential prms that can be made available to a user. Constraints are across or within a users session. No user may activate n or more roles from the roles set in each user session. Timely Revocation of Trust ensures that prms do not persist beyond the time that they are required for performance of duty.

DSD
SSD (RH) Role Hierarchy (UA) User Assignment USERS ROLES (PA) Permission Assignment OPS OBS

PRMS user_sessions session_roles

SESSIONS

DSD

Figure: Dynamic Separation of Duty relations. DSD relations place constraints on the roles that can be activated in a users 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

SYMMETRIC RBAC
Level 4
SOD Constraints (RH) Role Hierarchy (UA) User Assignment USERS ROLES (PA) Permission Assignment

P PERMISSIONS

user_sessions SESSIONS

. . .

Symmetric RBAC Dynamic SOD

SYMMETRIC RBAC
defines a requirement of reviewing the permission-role status The review interface or functionality has to provide
 y y y 

Direct permissions assignments User role permission assignments (UA) Objects sets and Role object permission assignment(PA) Indirect permission assignments assigned through a role inheritance

OTHER RBAC ATTRIBUTES

Scalability: The notion of scalability is multi-dimensional. In RBAC scalability with respect to number to roles, number of permissions, size of role hierarchy, limits on user-role assignments etc. The NIST model does not incorporate a scalability attribute but this is an important issue in choosing a product.


OTHER RBAC ATTRIBUTES



Authentication

The NIST model does not address the issue of authentication. How are individual users authenticated and associated with the roles to which they belong.

Negative Permissions The NIST model does not rule out of the use of so-called negative permissions which deny access.


OTHER RBAC ATTRIBUTES

Nature of Permissions Can be defined in terms of primitive operations such as read and write or abstract operations such as credit and debit.  Discretionary role activation Allow a user to activate multiple roles simultaneously Allow use of one role at a time Vendors can use to distinguish their products as they see fit


OTHER RBAC ATTRIBUTES

Roll engineering The NIST RBAC model does not provide guidelines for deigning roles and assigning permissions and user to rolls .  Constraints RBAC can also incorporate obligation constraints which require to happen. The concept of obligation constraints is considered too new to incorporate into a standard model .


RBAC ADMINISTRATION
RBAC administration roles The NIST RBAC model does not specify the authorization for assigning users to roles, permissions to roles and for revoking these assignments.  Role revocation The NIST RBAC model does not specify revocation behavior but it is an important issue to which vendors and users of RBAC products must pay careful attention.


CONCLUSION

Nowadays RBAC is becoming expected among large users and the number of vendors that are offering RBAC features is growing rapidly. This development continues without any general agreement as to what constitutes RBAC features .A authoritative definition of core RBAC features use in authorization management systems. Standardization over a core set of RBAC features is expected to provide a multitude of benefits include a common set of benchmarks for vendors who are developing RBAC mechanisms, to use in their product specifications.

THANK YOU !!!