RBAC and Usage ControlSystem Security

Role Based Access Control• Enterprises organise employees in different roles• RBAC maps roles to access rights• After Subjects are authenticated they can activate roles• Access rights are assigned per active roles

A simple example

Using ACL for 702

Andrew

Robert

Patricia

Sam

…

Using ACL @ Uni Level

Role to Access Rights

User to Role

Andrew

Robert

Patricia

Sam

From User to Access Right

Extensions to the Model• A user can be in more than one role• Robert Amor is both Prof. and Head of Department

• Roles can be organised into Hierarchies• Professor > Assistant Professor > Senior Lecturer > Lecturer• Top Roles inherit access rights of Lower Roles

• Constraints to enforce organisation-specific requirements

RBAC Constraints• Separation of Duties (SoD)• Protecting the organisation from frauds

• Chinese Wall (CW)• Conflict of interests between different domains

Separation of Duties Details• Used when an activity involves more than one role• Purchase order needs to be prepared by a clerk and then

authorized by a manager• To avoid a fraud, the user that prepares the order should not be

the same that authorizes it

Static Separation of Duties• The same subject cannot be a member of two mutually

exclusive roles• A clerk’s and a manager’s roles are mutually exclusive

• Too restrictive: the user might get assigned to both roles as long as they are not working on the same order!

Dynamic Separation of Duties• The same subject can be member of two mutually exclusive

roles• However, it requires extra checks that need to be done at

runtime to avoid undesired behaviour• Simple DSoD, Object DSoD, Operational DSoD, History DSoD

Controlling the usage of resources

• DAC, MAC and RBAC are concerned with checking the access rights of entities

• Once the access is granted no more controls are enforced

Examples• Read a file only 5 times• Write data into a directory but only up to 1 GB• Connect to the Internet only if there is enough remaining

bandwidth (capping plan)• Withdraw from ATM only if there is enough credit in account

Usage Control Model (UCON)• Focuses on controlling usage and not only access to an object• Addresses Digital Right Management (DRM) concerns• DAC, MAC and RBAC can also be expressed by UCON

UCON Model• Usage control is based on:• Authorizations• Obligations• Conditions• Mutability of Attributes• Continuity of Enforcement

• Finer grained control

Defined by J. Park and R. Sandhu The UCON Usage Control Model. ACM Trans. on Information and System Security, 7(1), 2004

Usage Control Model (UCON)• Applications• Simple, familiar, usable and effective use cases demonstrate the

need for UCON• Automatic Teller Machines• CAPTCHAs at Public web sites• End User License Agreements• Terms of Usage for WiFi in Hotels, Airports• Rate limits on call center worker

UCON (cont’d)

Subjects and Objects• Subjects: entities that perform actions on Objects. Are

characterized by Attributes:• Identity• Role• Reputation• Credits

• Objects: entities that are used by Subjects. Are characterized by Attributes:• Value• Identity• Status

Mutability of Attributes• Attributes of Subjects and Objects• Can be static (IMMUTABLE)• Can be updated (MUTABLE):

• Before the action execution (PRE)• During the action execution (ONGOING)• After the action execution (POST)

• Example: A storage service charges its users when they read documents. The credit attribute of an user is updated before he reads a document.

Authorization• Authorization rules are a set of requirements that should be

satisfied before allowing subjects’ access to objects or use of objects.• Rights-related Authorization Rules (RAR) and Obligation-related

Authorization Rules (OAR).• Functional predicates for usage decisions that evaluate:• Subject Attributes• Object Attributes• Right (Action)• Authorization rules

• Example: a computational service exploits a security policy to decide whether the user U can perform the action “read” on the file “a.txt”

Obligations• Conditions are a set of decision factors that the system should

verify at authorization process along with authorization rules before allowing usage of rights on a digital object. • Dynamic conditions and Static conditions

• Obligations are mandatory requirements that a subject has to perform after obtaining or exercising rights on an object.

• Functional predicates that verify mandatory requirements that must have been performed by the subject.• Actions• ...........

• Example: the user of a storage service must download the license agreement before downloading any other document.

Conditions• Environmental or system based decision factors• Not directly related with Subjects and Objects• e.g.

• Current local time• Current system workload• System status

• Example: night-users can submit jobs to a computational resource only from 8pm to 8am

Continuity• Mutable Attributes change their values• The evaluation of a usage right can be performed• Before the action (PRE)• Continuously during the action (ONGOING)

• The right could be revoked and the action interrupted• Used for long lived actions (days, months,..)

Resources• Chapter 8 in Mark Stamp, Information Security: Principles and

Practice, Wiley 2011.• Matt Bishop, Computer Security: Art and Science, Addison-

Wesley 2003.• Sandhu, et al. "Role-based access control models," Computer ,

vol.29, no.2, pp.38,47, Feb 1996 (doi: 10.1109/2.485845)

Questions?