# Presentation: 263055

## Role-Based Access Control

- Overview

## Objective

- Establish a common vocabulary for Role Based Access Control for use in SEPM
- Present a Framework for Role Based Access Control for both Physical and Virtual Domains
- Discuss Various AC Models and why RBAC is a must!!!!

## 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 may 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 develop cost and time frame.”
- 			 ** ****-*****The Economic Impact of Role-Based Access Control***

- The Time is NOW!

## 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.

- 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”**

- SIPRNET
- 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.

- “Ideally, the [RBAC] system is clearly defined and agile, making the addition of new applications, roles, and employees as efficient as possible”

## Role-Based AC

- _Individuals_

- _Roles_

- _Resources_

- 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

## Core Components (cont)

- Permissions (*prms*)
- Assigned Permissions
- Object Permissions
- Operation Permissions
- Sessions
- User Sessions
- Available Session Permissions
- Session Roles

## Constraint Components

- Role Hierarchies (*rh*)
- General
- Limited
- Separation of Duties
- Static
- Dynamic

## RBAC Transition 

| Models	 | Hierarchies | Constraints |
| --- | --- | --- |
| RBAC0 | No | No |
| RBAC1 | Yes | No |
| RBAC2 | No | Yes |
| RBAC3 | Yes | Yes |

- Most
- Complex

**Least Privileged**
**Separation of Duties**

- RBAC Model

- Effort

- RBAC3

## RBAC System and Administrative Functional Specification

- Administrative Operations
- Create, Delete, Maintain elements and relations
- Administrative Reviews
- Query operations
- System Level Functions
- Creation of user sessions
- Role activation/deactivation
- Constraint enforcement
- Access Decision Calculation

## Core RBAC

## USERS

- Process

- Person

- Intelligent Agent

## ROLES

- Developer

- Budget
- Manager

- Help Desk
- Representative

- An organizational job function with a clear definition of inherent responsibility and authority (permissions).

- Director

- MTM relation between
- USERS & PRMS

## OPS (operations)

- An execution of an a program specific function that’s invocated by a user.

- Database – Update  Insert  Append Delete
- Locks – Open   Close
- Reports – Create  View   Print
- Applications - Read  Write  Execute

- SQL

## OBS (objects)

- An entity that contains or receives information, or has exhaustible system resources.

- OS Files or Directories
- DB Columns, Rows, Tables, or Views
- Printer
- Disk Space
- Lock Mechanisms

- RBAC will deal with all the objects listed in the permissions assigned to roles.

## UA (user assignment)

- A user can be assigned to one or more roles

- Developer

- USERS set

- ROLES set

- Help Desk Rep

- A role can be assigned
- to one or more users

## UA (user assignment)

- Mapping of role *r *onto a set of users

- User.DB1
- View
- Update
- Append

- USERS set

- ROLES set

- User.DB1

- User.DB1

- permissions

- object

- User.F1
- User.F2
- User.F3

## PRMS (permissions)

- The set of permissions that each grant the approval to perform an operation on a protected object.

## PA (prms assignment)

- A prms can be assigned to one or more roles

- Admin.DB1

- PRMS set

- ROLES set

- A role can be assigned
- to one or more prms

- User.DB1

- View
- Update
- Append

- Create
- Delete
- Drop

## PA (prms assignment)

- PRMS set

- ROLES set

- User.F1
- User.F2
- User.F3
- Admin.DB1

- Mapping of role *r *onto a set of permissions

- Read
- Write
- Execute
- View
- Update
- Append
- Create
- Drop

- SQL

## PA (prms assignment)

- PRMS set

- OPS set

- Mapping of operations to permissions

- public int read(byteBuffer dst)
-          throws IOException
- Inherited methods from java.nio.channls
- close()
- isOpen()

- READ

- Gives the set of ops associated with the permission

## PA (prms assignment)

- Mapping of permissions to objects

- PRMS set

- Open
- Close
- View
- Update
- Append
- Create
- Drop

- SQL

- DB1.table1

- Objects

- BLD1.door2

- Gives the set of objects associated with the prms

## SESSIONS

- The set of sessions that each user invokes.

- USER

- SQL

- DB1.table1

- FIN1.report1

- APP1.desktop

- SESSION

## SESSIONS

- The mapping of user *u *onto a set of sessions.

- USERS

- SQL

- User2.DB1.table1.session

- User2.FIN1.report1.session

- User2.APP1.desktop.session

- SESSION

- USER2

- USER1

## SESSIONS

- The mapping of session *s *onto a set of roles

- SESSION

- ROLES

- Admin
- User
- Guest

- SQL

- DB1.table1.session

## SESSIONS

- Permissions available to a user in a session.

- View
- Update
- Append
- Create
- Drop

- PRMS

- ROLE

- SESSION

## Hierarchal  RBAC

*user_sessions*

- (RH)
- Role Hierarchy

*session_roles*

- (UA)
- User Assign-
- ment

- (PA)
- Permission
- Assignment

***USERS***

***OBS***

***OPS***

***SESSIONS***

***ROLES***

***PRMS***

## Tree Hierarchies

- Tree

- Inverted Tree

## Lattice Hierarchy

## RH (Role Hierarchies)

- Natural means of structuring roles to reflect organizational lines of authority and responsibilities
- General and Limited
- Define the inheritance relation among roles
-       i.e.      r1    *inherits*     r2

- User
- r-w-h

- Guest
- -r-

## General RH

**General RH**

- User
- r-w-h

- Guest
- -r-

- Only if all permissions of r1 are also permissions of r2

- Only if all users of r1 are also users of r2

-  i.e.      r1    *inherits*     r2

- Guest Role Set

- Power User Role Set

- User Role Set

- Admin Role Set

- Support Multiple Inheritance

## authorized users

- Mapping of a role onto a set of users in the presence of a role hierarchy

- User.DB1
- View
- Update
- Append

- First Tier USERS set

- ROLES set

- User.DB1

- User.DB1

- permissions

- object

- Admin.DB1
- User.DB2
- User.DB3

## authorized permissions

- Mapping of a role onto a set of permissions in the presence of a role hierarchy

- PRMS set

- ROLES set

- User.DB1
- User.DB2
- User.DB3
- Admin.DB1

- View
- Update
- Append
- Create
- Drop

- SQL

## Limited RH

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

- Role1

- Role2

- Role3

- Role2 inherits from Role1

- Role3 does not inherit from
- Role1 or Role2

## Limited RH (cont)

- 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

## 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)
- Dynamic Separation of Duties (DSD)

## 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.

## SSD in Presence of RH

- A constraint on the authorized users of the roles that have an SSD relation.
- Based on the authorized users rather than assigned users.
- Ensures that inheritance does not undermine SSD policies.
- Reduce the number of potential permissions that can be made available to a user by placing constraints on the users that can be assigned to a set of roles.

## 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 user’s 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 (cont)

- Reduce
- COI

## QUESTIONS...COMMENTS??