AMTRAC: An administrative model for temporal role-based access control

ww.sciencedirect.com

c om p u t e r s & s e c u r i t y 3 9 ( 2 0 1 3 ) 2 0 1e2 1 8

Available online at w

journal homepage: www.elsevier .com/locate/cose

AMTRAC: An administrative model fortemporal role-based access control

Manisha Sharma a, Shamik Sural a,*, Jaideep Vaidya b,Vijayalakshmi Atluri b

a School of Information Technology, Indian Institute of Technology, Kharagpur, IndiabMSIS Department and CIMIC, Rutgers University, USA

a r t i c l e i n f o

Article history:

Received 21 February 2013

Received in revised form

13 May 2013

Accepted 9 July 2013

Keywords:

Administrative model

Temporal RBAC

Role enabling base assignment

Administrative command

Role hierarchy

* Corresponding author. Tel.: þ91 3222 28233E-mail addresses: [email protected]

[email protected] (J. Vaidya), atluri@0167-4048/$ e see front matter ª 2013 Elsevhttp://dx.doi.org/10.1016/j.cose.2013.07.005

a b s t r a c t

Over the years, Role Based Access Control (RBAC) has received significant attention in

system security and administration. The Temporal Role Based Access Control (TRBAC)

model is an extension of RBAC that allows one to specify periodic enabling and disabling of

roles in a role enabling base (REB). While decentralized administration and delegation of

administrative responsibilities in large RBAC systems is managed using an administrative

role based access control model like ARBAC97, no administrative model for TRBAC has yet

been proposed. In this paper, we introduce such a model and name it AMTRAC (Admin-

istrative Model for Temporal Role based Access Control). AMTRAC defines a broad range of

relations that control user-role assignment, role-permission assignment, roleerole

assignment and role enabling base assignment. Since the first three are similar to those in

ARBAC97, the role enabling base assignment component has been discussed in detail in

this paper. The different ways by which role enabling conditions of regular roles can be

modified are first explained. We then show how to specify which of the administrative

roles are authorized to modify the role enabling conditions of any regular role. An

exhaustive set of commands for authorization enforcement along with their pre and

postconditions is also presented. Together, this would facilitate practical deployment and

security analysis of TRBAC systems.

ª 2013 Elsevier Ltd. All rights reserved.

1. Introduction indirection between users and permissions through roles

Organizations try to restrict access to their various resources

through access control mechanisms. A number of access

control models have been proposed in the last several years

that include Mandatory Access Control (MAC) (Osborn, 1997),

Discretionary Access Control (DAC) (Osborn et al., 2000), Role

Based Access Control (RBAC) (Sandhu et al., 1996) and Attri-

bute Based Access Control (ABAC) (Jin et al., 2012). Among

these, RBAC is considered to be well suited for authorization

enforcement in large organizations as it creates a level of

0.net.in (M. Sharma), shamrutgers.edu (V. Atluri).ier Ltd. All rights reserved

(Schaad et al., 2001).

For certain applications, which need to make access con-

trol decisions based on contextual information like location

and time, RBAC however is not adequate. To handle such re-

quirements, several variants and extensions of RBAC have

been proposed (Bertino et al., 2001; Aich et al., 2007; Aich et al.,

2009; Bertino et al., 2007; Ray et al., 2006; Joshi et al., 2005). The

Temporal Role Based Access Control (TRBAC) (Bertino et al.,

2001) model is an extension of RBAC that imposes temporal

constraints on role enabling conditions. It includes a Role

[email protected], [email protected] (S. Sural), jsvai-

.

mailto:[email protected]






http://crossmark.crossref.org/dialog/?doi=10.1016/j.cose.2013.07.005&domain=pdf

www.sciencedirect.com/science/journal/01674048

www.elsevier.com/locate/cose

http://dx.doi.org/10.1016/j.cose.2013.07.005




Enabling Base (REB) for defining periodic enabling and

disabling of roles expressed as periodic events with temporal

dependencies among roles specified using role triggers.

Managing a large number of roles necessitates decentral-

ization of administration, which delegates administrative

privileges among various administrative roles as it is over-

whelming for a single security officer to administer all the

roles. Several administrative models for RBAC have been

proposed like ARBAC97 (Sandhu et al., 1999), ARBAC99

(Sandhu and Munawer, 1999) and ARBAC02 (Sandhu and Oh,

2002). Of these, ARBAC97 includes URA97 for controlling user

to role assignment, PRA97 for controlling permission to role

assignment and RRA97 for controlling role to role assignment.

ARBAC99 incorporates the concept of mobile and immobile

users and permissions with URA and PRA, while RRA is left

unaltered. ARBAC02 does not make significant changes to the

basic features of ARBAC97 other than adding the concept of

organization structure as user and permission pools. Devel-

opment of such administrative models has facilitated

enterprise-level deployment of RBAC systems.

Besides providing a means for managing RBAC systems,

administrative models play an important part in analyzing

their security properties. Ever since the need for access

control mechanisms was conceived for authorization in

multi-user systems, development of access control models

has gone hand-in-hand with the development of formal

techniques for security analysis of systems implementing

such models. Influential results have been reported, among

others, for the Harrison, Ruzzo, Ullman (HRU) model

(Harrison et al., 1976; Tripunitara and Li, 2013), Take Grant

Protection model (Synder, 1977), Typed Access Model

(Sandhu, 1992), Schematic protection model (Sandhu, 1988)

and Extended Schematic Protection Model (Ammann and

Sandhu, 1991). The overall flow of security analysis involves

representation of the system as a state model, delineation of

state transition rules and specification of the desired prop-

erties using a formal language. A suitable formal analysis

Fig. 1 e Conceptual dia

methodology like model checking is then followed for veri-

fying the safety (often liveness and non-blocking properties

as well). For RBAC, state transition rules are defined through

administrative policies, which in turn, are based on the

chosen administrative model. Li et al. (Li and Tripunitara,

2006) consider AATU (Assignment And Trusted Users) and

AAR (Assignment and Revocation), that use assignment and

revocation relations similar to those proposed in URA97, for

defining a family of security analysis problems in RBAC. Jha

et al. (Jha et al., 2008) also define security analysis problems

in RBAC using URA97.

Although security analysis of TRBAC has been done to a

certain extent in (Uzun et al., 2012) and (Mondal and Sural,

2008), none of these consider a formal administrative model

for TRBAC. Uzun et al. (Uzun et al., 2012), in a bid to perform

security analysis, propose some administrative functions for

temporal RBAC. However, no complete administrative model

has been proposed by them that can also be suitably used for

administering a TRBAC system. It is thus seen that, unlike

RBAC, absence of a formal administrative model severely re-

stricts the proliferation of enterprise e level deployment of

TRBAC.

To address these shortcomings, an administrative model

for TRBAC is proposed in this paper. We denote it as AMTRAC

(Administrative Model for Temporal Role-based Access Con-

trol). A number of relations are defined in AMTRAC for man-

aging user-role assignment, role-permission assignment,

roleerole assignment and role enabling base assignment as

shown in Fig. 1. Of these, the first three are similar to those

used in ARBAC97, namely, URA, PRA and RRA. It may be noted

that, since distinction between mobile and immobile users

and permissions is not considered in core TRBAC, we do not

use ARBAC99 as the underlying non-temporal component for

developing AMTRAC. Similarly, the use of organizational

structure for defining user and permission pools as done in

ARBAC02 is not considered essential for administering the

non-temporal components of the basic TRBAC model. Hence,

gram for AMTRAC.



c om p u t e r s & s e c u r i t y 3 9 ( 2 0 1 3 ) 2 0 1e2 1 8 203

we build AMTRAC over the features supported by ARBAC97.

However, if the core TRBAC model is upgraded with mobility

and use of organizational structure as supported in ARBAC99

and ARBAC02, respectively, AMTRAC can also be suitably

enhanced to include more rich non-temporal relations.

The main contribution of AMTRAC is that it includes a set

of eighteen new relations for managing the REB (Bertino

et al., 2001) of a TRBAC system. This set of relations is

collectively named as REBA (Role Enabling Base Assignment).

Nine of these relations (R1 to R9) are used to specify which of

the administrative roles can modify the periodic events of

regular roles. There are six relations (R10 to R15) to manage

modifications in role triggers. Adding of new members to an

existing REB is handled by two relations (R16 and R17) while

one relation (R18) is used for removing existing members from

the REB.

We also specify a set of commands alongwith their pre and

Postconditions that can be used to administer a TRBAC system

using AMTRAC. Successful execution of each of these com-

mands requires the administrative user to have requisite

permission to execute the command as specified in the above-

mentioned relations capturing the system administration

policies and also the preconditions to be satisfied. On

completion of execution, the set of corresponding post-

conditions should hold for each command.

The rest of the paper is organized as follows. Pre-

liminaries on the various components of RBAC, TRBAC and

ARBAC97 are briefly described in Section 2. We introduce the

proposed administrative model for TRBAC in Section 3. All

the different relations supported by the model and their

corresponding commands are included in this section. An

illustrative example is given in Section 4 to explain how the

various commands work together to administer a TRBAC

system. In Section 5, we present related work and finally,

Section 6 concludes the paper providing directions for future

research.

2. Preliminaries

This section builds the necessary background for an under-

standing of the various components of the proposed AMTRAC

model. In the first two sub-sections, we introduce the basic

components of RBAC and TRBAC, respectively. The third sub-

section gives an overview of the administrative RBAC model

on which AMTRAC is based.

2.1. Role based access control model (RBAC)

RBAC is amodel for restricting system access to its authorized

users by assigning them to requisite roles. In an organization,

roles are created for particular job functions. The permissions

to perform those functions are assigned to specific roles. Users

are assigned to a set of roles, and through permission-role

assignments, they acquire the necessary permissions to

perform various tasks. RBAC includes the following

components:

i. Sets Users, Roles, Perms and Sessions represent the set of

users, roles, permissions and sessions, respectively.

ii. UA: Users / Roles, the user-role assignment relation,

assigns users to roles.

iii. PA: Roles / Perms, the permission-role assignment

relation, assigns permissions to roles.

iv. user: Sessions / Users, assigns each session to a single

user.

v. role: Sessions / Roles, assigns each session to a set of

roles.

vi. RH 4 Roles � Roles, a partial order representing role

hierarchy.

The above-mentioned components of RBAC are shown in

Fig. 1.

2.2. Temporal role based access control model (TRBAC)

TRBAC (Bertino et al., 2001) is an extension of RBAC that

imposes temporal constraints on role enabling and

disabling conditions. It supports periodic role enabling and

disabling of roles as well as temporal dependencies among

roles expressed in the form of role triggers. Role trigger

actions may be either immediately executed, or delayed by

a specified amount of time. Role enabling and disabling

actions may be given a priority for resolving conflicting

actions. Both role enabling and disabling conditions as

well as role triggers of TRBAC are specified in a role

enabling base (REB), which is described next (Refer to

Fig. 1).

Role Enabling Base is a collection of periodic events and

role triggers for applying temporal constraints on roles. It is

formally defined as a set of elements of the following two

kinds:

(i) Periodic Event: A Periodic Event represents the enabling

and disabling conditions of roles. It is of the form (I, P, p:E )

comprising of:

(a) Time Interval I. It is a tuple of the form [beg,end] denoting

the start and end times during which the periodic event

is valid.

(b) Periodic Expression P. It denotes an infinite set of peri-

odic time instants. The definition of periodic expres-

sions is based on the idea of calendars. A calendar is

defined as a countable set of contiguous intervals

numbered by integers called indexes of the intervals.

There can be a sub-calendar relationship between

calendars. Given two calendars Cal1 and Cal2, Cal1 is

sub-calendar of Cal2 (Cal1 4 Cal2), if each interval of

Cal2 is exactly covered by a finite number of intervals

of Cal1.

Given calendars Cald, Cal1,... Caln, a periodic

expression is represented as:

P ¼ Pni¼1 Oi$Cali8r$Cald where O1 ¼ all, Oi˛2ZWfallg,

Cali 4 Cali�1, for i ¼ 2,., n, Cald 4 Caln, and r ˛ Z. The

symbol 8 divides a periodic expression into two parts.

The left part represents the set of starting points of

the intervals that the periodic expression represents

while the right part captures the duration of each

interval. As an example, consider the following peri-

odic expression:




all:yearsþ all:monthsþ all:weeksþ f1;2; 4g:days
þ 10:hours88:hours:
The above periodic expression represents a set of time in-

tervals starting at the tenth hour of the first, second and

fourth day of every week of every month of every year and

having a duration of eight hours.

(c) Prioritized event expression p:E. Here p ˛ prios, a pre-

defined totally ordered set of priorities, denotes the

priority of a simple event expression E. A simple event

expression E is of the form enable R or disable R, where

R represents a role. As an example, consider a periodic

event of the form:

ð½01=01=2013; 31=12=2016�; ðall:yearsþ all:months

þ all:weeksþ f1; 2;4g:daysþ f10g:hours88:hoursÞ;VH : enable doctorÞ:

It means that during the interval of 01/01/2013 to 31/12/

2016, enable the role doctor for a duration of eight hours with

Very High (VH) priority at 10:00 AM on the first, second and

fourth day of every week of every month of every year.

(ii) Role Trigger: Temporal dependency among roles is

captured by a role trigger represented in the form of the

following expression:

E1, E2,..., En,S1,S2,..., Sm / p:E after Dt, where Eis are

simple event expressions, Sjs are role status expressions, p:E

is a prioritized event expression and Dt is a delay expres-

sion. Here a role status expression gives the current state of

a role. It is of the form enabled R or :enabled R, where R

represents a role. As an example, consider a role trigger of

the form:

enable nurse; enabled doctor/H : enable technician after 1:

It means that the technician role must be enabled with high

priority one hour after the nurse role is enabled provided the

doctor role is already enabled.

2.3. Administrative RBAC model (ARBAC97)

The administrative RBAC (ARBAC97) model uses RBAC to

administer roles within an RBAC system. It consists of three

components, namely, URA97-user to role assignment, PRA97-

permission to role assignment and RRA97-role to role

assignment as shown in Fig. 1. It specifies two concepts: role

range and prerequisite condition. The set of regular roles R,

and the set of administrative roles AR, are assumed to be

disjoint. A role range specifies a set of roles, and an open role

range is written as (x, y), where x and y are regular roles. If a

role r1 is senior to another role r2 in the role hierarchy, it is

denoted as r1 > r2. By definition, ðx; yÞ ¼ frj:r < x^r > yg, where

r ˛ R. Ranges in URA97 and PRA97may be open, closed or half-

open. A precondition is a conjunction of literals, where each

literal is either in positive form r or in negative form:r, forsome role r in R. A prerequisite condition is evaluated for a

user u by interpreting r to be true if ðdr� r0Þðu; r0Þ˛UA and :r tobe true if ðcr0 � rÞðu; r0Þ;UA.

URA97 defines two relations: Can_assign and Can_revoke, to

control user-role assignment. Changes to the user-role

assignment relation UA can be allowed by using assignment

(or revocation) rules defined by Can_assign (or Can_revoke).

Administrative users are users who are assigned to adminis-

trative roles. Can_assign is of the form <a,c,b> where a is an

administrative role, c is a precondition and b is a role range.

The ordered triple<a,c,b> represents the fact thatmembers of

administrative role a can assign a user u to any role which

belongs to the range b provided u fulfills the precondition c.

Can_revoke is of the form <a,b> where a is an administrative

role and b is a role range. <a,b> implies that members of

administrative role a can remove a user from any role which

belongs to the range b.

PRA97 introduces two relations Can_assignp and Can_revo-

kep which are similar to Can_assign and Can_revoke respec-

tively. Can_assignp is of the form <a,c,b>. It means that a

member of the administrative role a (or senior to a) can assign

a permission to any regular role which belongs to the role

range b provided the current membership of user of the reg-

ular role fulfills the precondition c. Can_revokep is of the form

<a,b>. It denotes that a member of the administrative role a

(or senior to a) can revoke a permission from any regular role

which belongs to the role range b.

RRA97 defines a relation Can_modify for changing the role

hierarchy. It is of the form<a,b>, where a is an administrative

role and b is an encapsulated range. Encapsulated range is an

open range (x, y) which satisfies the condition that given a role

r1 ˛ (x, y) and a role r2 ; (x, y), r2 < r1 if and only if r2 � y, and

r1 < r2 if and only if r2 � x.

With this background, we next propose amodel that can be

used to define policies for administering the various compo-

nents of TRBAC.

3. Administrative model for TRBAC

In this section, we present a model for administering TRBAC,

which is named as AMTRAC (Administrative Model for Tem-

poral Role-based Access Control). AMTRAC can be used to

administer roles, user to role mapping, permission to role

mapping and role to role mapping as done in ARBAC97. In

addition, it also handles the temporal role enabling and

disabling conditions and temporal dependencies among roles.

AMTRAC consists of the following components:

1. URA (User to role assignment)

2. PRA (Permission to role assignment)

3. RRA (Role to role assignment)

4. REBA (Role Enabling Base Assignment)

User-role assignment is controlled by the relations defined

in URA97, Permission-role assignment is controlled by the re-

lations defined in PRA97 while Roleerole assignment is

controlled by the relations defined in RRA97. Since these com-

ponents do not differ from the earlier proposals, in this paper,

we focus on the fourth component, i.e., REBA. It is also the only

component that includes temporal aspects of AMTRAC.



Table 1 e Administrative commands for periodic eventmodification along with their corresponding relations,preconditions and postconditions.

C1 Modify_REB_PE_P_O1 (a0, b, PE, Calnew, Onew, O1new)

R1 Can_Modify_REB_PE_P_O1 (a, r)

PRE1 PE ˛ REB, Cal1 4 Calnew, Onew ¼ all, O1new˛2ZWfallgPOST1 P0 ¼ Pn0

i¼1 O0i$Cal

0i8r0$Cal0d where n0 ¼ nþ1,

O02 ¼ O1new; Cal02 ¼ Cal1; O0

kþ1 ¼ Ok, for k ¼ 2 to n,

Cal0kþ1 ¼ Calk for k ¼ 2 to n, O01 ¼ Onew, Cal01 ¼ Calnew,

r0 ¼ r, Cal0d ¼ Cald, PE0 ¼ (I, P0, p:E), REB ¼ (REB\PE)WPE0

C2 Modify_REB_PE_P_comporange (a0, b, PE, k, Onew)

R2 Can_Modify_REB_PE_P_comporange (a, r, i, j)

PRE2 PE ˛ REB, 2 � i � n, 2 � j � n, i � j, i � k � j,

Onew˛2ZWfallgPOST2 P0 ¼ Pn0

i¼1 O0i$Cal

0i8r0$Cal0d where n0 ¼ n, O0

l ¼ Ol

for l ¼ 1 to k�1, O0k ¼ Onew; O0

l ¼ Ol, for l ¼ kþ1 to n,

Cal0l ¼ Call for l ¼ 1 to n, r0 ¼ r, Cal0d ¼ Cald, PE0 ¼ (I, P0, p:E),REB ¼ (REB\PE)WPE0

C3 AddCal_REB_PE_P_calrange (a0, b, PE, k, Calnew, Onew)

R3 Can_AddCal_REB_PE_P_calrange (a, r, i, j)

PRE3 PE ˛ REB, 2 � i � n, 2 � j � n, i � j, i � k � j,

Calnew4Calk�1; Calk4Calnew; Onew˛2ZWfallgPOST3 P0 ¼ Pn0

i¼1 O0i$Cal

0i8r0$Cal0d where n0 ¼ n þ 1,

O0lþ1 ¼ Ol for l ¼ k to n, Cal0lþ1 ¼ Call for l ¼ k to n,

O0k ¼ Onew; Cal0k ¼ Calnew; O0

l ¼ Ol, for l ¼ 1 to k�1,

Cal0l ¼ Call for l ¼ 1 to k�1, r0 ¼ r, Cal0d ¼ Cald,

PE0 ¼ (I, P0, p:E), REB ¼ (REB\PE)WPE0

C4 AddCal_REB_PE_P_Caln (a0, b, PE, Calnew, Onew)

R4 Can_AddCal_REB_PE_P_Caln (a, r)

PRE4 PE ˛ REB, Calnew 4 Caln, Cald 4 Calnew,

Onew˛2ZWfallgPOST4 P0 ¼ Pn0

i¼1 O0i$Cal

0i8r0$Cal0d where n0 ¼ n þ 1,

O0l ¼ Ol for l ¼ 1 to n, Cal0l ¼ Call for l ¼ 1 to n,

O0n0 ¼ Onew; Cal0n0 ¼ Calnew, r0 ¼ r, Cal0d ¼ Cald,


C5 DeleteCal_REB_PE_P_Cal1 (a0, b, PE)R5 Can_DeleteCal_REB_PE_P_Cal1 (a, r)

PRE5 PE˛REB, n � 2

POST5 P0 ¼ Pn0i¼1 O

0i$Cal

0i8r0$Cal0d where n0 ¼ n�1,

O0l�1 ¼ Ol for l ¼ 3 to n, Cal0l�1 ¼ Call for l ¼ 3 to n,

O01 ¼ all; Cal01 ¼ Cal2, r0 ¼ r, Cal0d ¼ Cald, PE

0 ¼ (I,

P0, p:E), REB ¼ (REB\PE)WPE0

C6 DeleteCal_REB_PE_P_Calrange (a0, b, PE, k)R6 Can_DeleteCal_REB_PE_P_Calrange (a, r ,i ,j)

PRE6 PE ˛ REB, 2 � i � n, 2 � j � n, i � j, i � k � j, n � 2

POST6 P0 ¼ Pn0i¼1 O

0i$Cal

0i8r0$Cal0d where n0 ¼ n�1,

O0l ¼ Ol for l ¼ 1 to k�1, Cal0l ¼ Call for l ¼ 1 to k�1,

O01�1 ¼ Ol for l ¼ kþ1 to n, Cal01�1 ¼ Call for l ¼ kþ1 to n,

r0 ¼ r, Cal0d ¼ Cald, PE0 ¼ (I, P0, p:E), REB ¼ (REB\PE)WPE0

C7 Modify_duration_REB_PE_P (a0, b, PE, rnew, Caldnew)R7 Can_Modify_duration_REB_PE_P (a, r)

PRE7 PE ˛ REB, rnew˛Z; Caldnew4CaldPOST7 P0 ¼ Pn0

i¼1 O0i$Cal

0i8r0$Cal0d where n0 ¼ n, O0

l ¼ Ol for l ¼ 1

to n, Cal0l ¼ Call for l ¼ 1 to n, r0 ¼ rnew, Cal0d ¼ Caldnew,


C8 Modify_priority_REB_PE (a0, b, PE, p0)R8 Can_Modify_priority_REB_PE (a, r)

PRE8 PE ˛ REB, p0 ˛ prios

POST8 PE0 ¼ (I, P, p0:E), REB ¼ (REB\PE)WPE0

C9 Modify_Interval_REB_PE (a0, b, PE, Inew)R9 Can_Modify_Interval_REB_PE (a, r)

PRE9 PE ˛ REB

POST9 PE0 ¼ (Inew, P, p:E), REB ¼ (REB\PE)WPE0


REBA consists of a set of eighteen relations j{R1,R2,.,R18},

that specifies which administrative role is authorized to

modify role enabling base of which role range.

The system state is represented by a where a is a tuple

<g,s>. Here g represents the set of system components and s

is a set of state transition rules.

g ¼ fUA; PA; RH; REBg

s ¼fcan assign; can revoke; can assignp;

can revokep; can modify; jg

The set of features supported by the model includes

administrative relations (used to determine authorizations)

and administrative commands (used to change the system

state). Tables 1e4 summarize all the administrative com-

mands (denoted by Cis) along with their corresponding re-

lations (denoted by Ris), preconditions (denoted by PREis) and

postconditions (denoted as POSTis). Administrative relations

control the modifications that can be made to the REB of a

system. In other words, these relations determine the admin-

istrative roles which are authorized to change the periodic

enabling and disabling conditions of regular roles and tempo-

ral dependencies among regular roles.An instanceof this set of

relations represents the currently effective administrative

policy of the system. Overall, the set of identified administra-

tive features provides a comprehensive coverage for all the

management tasks required to administer a TRBAC system.

In the following two sub-sections we present details of the

administrative relations supported in REBA and the various

commands that can be used to change the system state.

3.1. Administrative relations in REBA

Each administrative relation is of the form Ri( y1,y2,..yli )

with y1,y2,..yli as its parameters. Parameters y1 and y2respectively denote administrative role a and role range r

where a ˛ AR and r ˛ 2R.

REB of a TRBAC system can be modified in a number of

ways, namely, updating the periodic events, changing the role

triggers, adding new periodic events (or role triggers) to the

REB and deleting the existing periodic events (or role triggers)

from the REB. These relations can be divided into four broad

categories as shown in Fig. 2:

Category 1: Modification in periodic events

Category 2: Modification in role triggers

Category 3: Addition of new members to REB

Category 4: Deletion of members from REB

In the following sub-sections, we describe the relations in

each category in detail.

3.1.1. Modification in periodic eventsA periodic event of the form (I, P, p:E ) can be modified by

changing either the periodic expression, the priority of the

prioritizedevent or the interval.On thebasis of these threeways

of modifying periodic events, the relations which belong to this

category can be further divided into the following three groups:

Group 1: Modification in periodic expression P



Table 2 e Administrative commands for role trigger modification along with their corresponding relations, preconditionsand postconditions.

C10 Add_event-expression_REB_RT (a0, b, RT, Enew) C11 Delete_event-expression_REB_RT (a0, b, RT, k)R10 Can_Add_event-expression_REB_RT (a, r) R11 Can_Delete_event-expression_REB_RT (a, r)

PRE10 RT ˛ REB PRE11 RT ˛ REB, 1 � k � x

POST10 RT0 ¼ E01;E

02..;E0

x0 ; S01; S

02;..S0y0/p0 : E after

Dt0 where x0 ¼ xþ1, y0 ¼ y, p0 ¼ p, t0 ¼ t,

E0l ¼ El for l ¼ 1 to x, S0l ¼ Sl for l ¼ 1 to y,

E0x0 ¼ Enew, REB ¼ (REB\RT)WRT0

POST11 RT0 ¼ E01;E

02..;E0

x0 ;S01; S

02;..S0y0/p0 : E after Dt0

where x0 ¼ x�1, y0 ¼ y, p0 ¼ p, t0 ¼ t, E0l ¼ El for

l ¼ 1 to k�1, E0l�1 ¼ El for l ¼ kþ1 to x, S0l ¼ Sl for

l ¼ 1 to y, REB ¼ (REB\RT)WRT0

C12 Add_role-status-expression_REB_RT (a0, b, RT, Snew) C13 Delete_role-status-expression_REB_RT (a0, b, RT, k)R12 Can_Add_role-status-expression_REB_RT (a, r) R13 Can_Delete_role-status-expression_REB_RT (a, r)

PRE12 RT ˛ REB PRE13 RT ˛ REB, 1 � k � y

POST12 RT0 ¼ E01;E

02..;E0

x0 ; S01; S


where x0 ¼ x, y0 ¼ yþ1, p0 ¼ p, t0 ¼ t, E0l ¼ El

for l ¼ 1 to x, S0l ¼ Sl for l ¼ 1 to y, S0y0 ¼ Snew,

REB ¼ (REB\RT)WRT0

POST13 RT0 ¼ E01;E

02..;E0

x0 ;S01; S


where x0 ¼ x, y0 ¼ y�1, p0 ¼ p, t0 ¼ t, E0l ¼ El for

l ¼ 1 to x, S0l ¼ Sl for l ¼ 1 to k�1, S0l�1 ¼ Sl for

l ¼ k þ 1 to y, REB ¼ (REB\RT)WRT0

C14 Modify_priority_REB_RT (a0, b, RT, p0) C15 Modify_delay_REB_RT (a0, b, RT, t0)R14 Can_Modilfy_priority_REB_RT (a, r) R15 Can_Modify_delay_REB_RT (a, r)

PRE14 RT ˛ REB, p0 ˛ prios PRE15 RT ˛ REB

POST14 RT0 ¼ E01;E

02..;E0

x0 ; S01; S


where x0 ¼ x, y0 ¼ y, t0 ¼ t, S0l ¼ Sl for l ¼ 1 to y,

E0l ¼ El for l ¼ 1 to x, REB ¼ (REB\RT)WRT0

POST15 RT0 ¼ E01;E

02..;E0

x0 ;S01; S


where x0 ¼ x, y0 ¼ y, p0 ¼ p, S0l ¼ Sl for l ¼ 1 to y,

E0l ¼ El for l ¼ 1 to x, REB ¼ (REB\RT)WRT0


Group 2: Modification in priority p of event E

Group 3: Modification in interval I

3.1.1.1. Modification in periodic expression. In Group 1, there

are seven relations that govern which administrative role is

authorized to modify the periodic expression of the periodic

event of which role range. Relations R1 and R2 control modi-

fication of components associated with calendars in periodic

expressions. R1 controls modification of the first component

(O1) of the periodic expression of a periodic event and R2

controls modification of all the other components (O2,

O3,.,On). A separate relation is needed for controlling modi-

fication made in the O1 component since according to the

periodic expression definition, the first component must be

all. Hence, all needs to be added as the first component to the

periodic expression.

Relations R3 and R4 control addition of a new calendar to a

periodic expression. R3 controls addition of a new calendar

within the range Cali to Calj (such that Calj 4 Cali, i � j,

1 � i � (n�1) and 1 � j � (n�1), where n is the number of

Table 3 e Administrative commands for addition of newmembers to REB along with their correspondingrelations, preconditions and postconditions.

C16 Add_PE (a0, b, PEnew)R16 Can_Add_PE (a, r)

PRE16 PEnew is of the form (I, P, p:E )

POST16 REB ¼ REB W PEnewC17 Add_RT (a0, b, RTnew)

R17 Can_Add_RT (a, r)

PRE17 RTnew is of the form (E1, E2,..., Ex,S1,S2,...,Sy /

p: E after Dt)

POST17 REB ¼ REB W RTnew

calendars in the periodic expression). R4 adds a new calendar

after Caln in the periodic expression of a periodic event. The

calendar Cald of any periodic expression must be a sub-

calendar of Caln. R4 handles this constraint. Relations R5 and

R6 control deletion of a calendar from a periodic expression. R5

controls deletion of the first calendar in a periodic expression.

The first component of a periodic expression must be all and

R4 captures this requirement. R6 controls deletion of a calen-

dar that belongs to the range Cali to Calj (such that Calj 4 Cali,

i � j, 2 � i � n and 2 � j � n, where n is the number of calendars

in the periodic expression).

Relation R7 controls modification of the duration of a pe-

riodic expression.

3.1.1.2. Modification in priority. In Group 2, there is a relation

R8 which controls modification of the priority of a periodic

event.

3.1.1.3. Modification in interval. Relation R9 comes under

Group 3 and it controls modification of the interval of a peri-

odic event.

3.1.2. Modification in role triggersRole triggers can be modified by adding or deleting the event

expression, by adding or deleting the role status expression,

Table 4 e Administrative commands for deletion ofmembers from REB along with their correspondingrelations, preconditions and postconditions.

C18 Delete_RT (a0, b, RT)R18 Can_Delete_RT (a, r)

PRE18 RT ˛ REB

POST18 REB ¼ REB\RT



Fig. 2 e Components of REBA. Ri denotes relation i as given in Tables 1e4.


by changing the priority of a prioritized event or by changing

the delay. Relations R10eR15 control modification in role trig-

gers. R10 controls addition of a new event expression to a role

trigger. R11 controls deletion of an event expression froma role

trigger. R12 controls addition of a new role status expression to

a role trigger. R13 controls deletion of role status expression

from a role trigger. R14 and R15 respectively control modifica-

tion of priority and delay expression of a role trigger.

3.1.3. Addition of new members to REBTwo relations R16 and R17 fall under this section. R16 controls

addition of a new periodic event for a role. R17 controls addi-

tion of a new role trigger for a role.

3.1.4. Deletion of members from REBThis section deals with the deletion of periodic events and role

triggers from REB. In this category, there is only one relation

R18 that controls deletion of role triggers from an REB since

deletion of periodic events can be controlled by the relation R7

by setting the value of duration to zero.

In the next sub-section, the administrative commands of

REBA are discussed in detail. A generic algorithm named

exec_cmd (Algorithm 1) is also proposed, which is used to

operationalize all the administrative commands.

3.2. Administrative commands in REBA

The administrative commands are used to change the state of

a TRBAC system by making a change in one of the system

components, which include UA, PA, RH and REB. In this paper,

only those commands are described which cause changes to

the REB of a system. Tables 1e4 list all the administrative

commands. For each command Ci, there are two sets of con-

ditions: preconditions PREi and postconditions POSTi. Only if

the corresponding relation Ri permits, can Ci be executed. For

successful execution of the command Ci, all the preconditions

that belong to the set PREi must be satisfied prior to its

execution and all the postconditions that belong to the set

POSTi must hold after its execution. Each command is of the

form Ci(x1,x2,..xki ) with x1,x2,..xki as its parameters. Pa-

rameters x1 and x2 of each command denote administrative

role Sy/ and role b where a0˛AR and b ˛ R.

All the commands listed in Tables 1e4 follow the common

structure of Algorithm 1. Corresponding to every command

Ci, there exists a relation Ri in the respective table which

controls the execution of that command. All these relations

together specify the system state transition rules. If a state

transition rule (relation) permits, only then is a command

allowed to execute. The proposed algorithm first invokes a

boolean function evaluate whose parameters are command Ci

and relation Ri to determine whether the system should allow

execution of this command. If evaluate returns false, then the

algorithm terminates giving an appropriate error message. If




it returns true, preconditions included in the set PREi are

evaluated. Only if all the preconditions evaluate to true, does

the execution of the command proceed. Otherwise the algo-

rithm terminates. On successful execution of the command

Ci, all the postconditions in the set POSTi should evaluate to

true.

The algorithm for the function evaluate is given as Algo-

rithm 2. In this algorithm, the administrative role a0 of Ci and

administrative role a of Ri are compared. If a0 is senior to a and

role b belongs to the role range r then it returns true, where

role b is a parameter of Ci and role range r is a parameter of Ri.

In other words, any member of the administrative role a (or

senior to a) is authorized to modify the REB of any role which

belongs to the role range r.

Like administrative relations, administrative commands

can also be divided into four categories: periodic event

modification, role trigger modification, addition of new

members to REB and deletion of members from REB. We next

describe the commands in each category in the following sub-

sections.

3.2.1. Periodic event modificationIn this sub-section, we describe nine administrative com-

mands (C1 to C9) which can modify periodic events.

Command C1: Modify_REB_PE_Pexp_O1 (a0, b, PE, Calnew, Onew,

O1new)

In this command, the admin role all modifies the first

component (O1) associated with the calendar Cal1 in a periodic

expression of the periodic event PE of a regular role b to O1new.

To modify the first component, at least one new calendar

denoted by Calnew with component Onew needs to be added to

the leftmost side of a periodic expression for satisfying the

periodic expression property.

The set PRE1 includes the following preconditions for C1:

The periodic event PE should belong to the REB of the system,

calender Cal1 of the periodic expression of the periodic event

PE should be a sub-calendar of Calnew, Onew should be equal to

all and O1new should belong to the set 2ZWfallg.The set POST1 includes the following postconditions for

C1: The new periodic event PE0 is of the form (I, P0, p:E ),

whose interval and prioritized event remain the same as

that of PE while the periodic expression is given by

P0 ¼ Pn0i¼1 O

0i$Cal

0i8r0$Cal0d. In the periodic expression P0, the

number of calendars is one more than that in P, the com-

ponents O03 to O0

nþ1 are updated by their corresponding pre-

ceding components in P (i.e., O2 to On), the calendars Cal03 to

Cal0nþ1 are updated by their corresponding preceding com-

ponents in P (i.e., Cal2 to Caln), the components O1 and O2 are

updated by Onew and O1new, the calendars Cal01 and Cal02 are

updated by Calnew and Cal1 and the duration remains the

same as that of P. In the REB, PE is updated by PE0.

Command C2: Modify_REB_PE_Pexp_comporange (/, b, PE,

k, Onew)

In this command, the admin role a0 modifies the compo-

nent associatedwith the calendar Calk in a periodic expression

of the periodic event PE of a regular role b.


The periodic event PE (I, P, p:E ) should belong to the REB of the

system, k should lie in the range (i, j ), where i and j are pa-

rameters of relation R1 such that i and j both lie in range 2 to n,

where n is the number of calendars in the periodic expression

P and i � j, Onew should belong to the set 2ZWfallg.The set POST2 includes the following postconditions for C2:

The new periodic event PE0 is of the form (I, P0, p:E ), whose in-

terval andprioritized event remain the sameas that of PEwhile

the periodic expression is given by P0 ¼ Pn0i¼1 O

0i$Cal

0i8r0$Cal0d. In

the periodic expression P0, the number of calendars, duration,

calendars Cal01 to Cal0n and components O01 to O0

n remain the

sameas thatofPexceptO0k which isupdatedbyOnew. In theREB,

PE is updated by PE0.

Command C3: AddCal_REB_PE_Pexp_calrange (a0, b, PE, k,

Calnew, Onew)

In this command, the admin role a0 adds a new calendar

Calnew between calendars Calk�1 and Calk in a periodic

expression of the periodic event PE of a regular role b.






P and i � j, Calnew should be a sub-calendar of Calk�1, Calkshould be a sub-calendar of Calnew and Onew should belong to

the set 2ZWfallg.The set POST3 includes the following postconditions for C3:


terval andprioritized event remain the sameas that of PEwhile


0i$Cal

0i8r0$Cal0d. In

theperiodic expressionP0, thenumberof calendars is onemore

than that in P, calendars Cal0i to Cal0k�1 and components O1 to

Olþ1 are updated by their corresponding elements in P, com-

ponentsO0kþ1 toOnþ1 and calendars Calkþ1 to Calnþ1 are updated

by their corresponding preceding elements in P, O0k is updated

by Onew and Calk is updated by Calnew, while duration remains

the same as that of P. In the REB, PE is updated by PE0

Command C4: AddCal_REB_PE_Pexp_Caln (a0, b, PE, Calnew, Onew)

In this command, the admin role a0 adds a new calendar Calnewafter the calendar Caln in a periodic expression of the periodic

event PE of a regular role b.



system, Calnew should be a sub-calendar of Caln, Cald should be

a sub-calendar of Calnew and Onew should belong to the set

2ZWfallg.The set POST4 includes the following postconditions for C4:

The new periodic event PE0 is of the form (I, PE ˛ REB, p:E ),

whose interval and prioritized event remain the same as that

of PE while the periodic expression is given by

P0 ¼ Pn0i¼1 O

0i$Cal

0i8r0$Cal0d. In the periodic expression P0, the

number of calendars is onemore than that in P, calendars Cal01to Cal0n, components O0

1 to O0n and duration remain the same as

that of P while O0nþ1 is replaced by Onew and Cal0nþ1 is replaced

by Calnew. In the REB, PE is updated by PE0.




Command C5: DeleteCal_REB_PE_Pexp_Cal1 (a0, b, PE )

In this command, the admin role a0 deletes the calendar Cal1from a periodic expression of the periodic event of a regular

role b.



system and n � 2.

The set POST5 includes the following postconditions for C5:


terval andprioritizedevent remain the sameas that of PEwhile


0i$Cal

0i8r0$Cal0d. In

theperiodic expressionCaldnew4Cald, thenumberof calendars

is reduced by one, the components O02 to O0

n�1 are updated by

their corresponding succeeding components in P, calendars

Cal02 to Cal0n�1 are updated by their corresponding succeeding

calendars in P,O1 is updatedbyall,Cal1 is updatedbyCal2,while

duration remains the same as that of P. In the REB, PE is

updated by PE0.

Command C6: DeleteCal_REB_PE_Pexp_Calrange (a0, b, PE, k)

In this command, the admin role a0 deletes calendar Calk fromthe periodic expression of the periodic event of a regular role b.






P, i � j and n � 2.



terval andprioritizedevent remain the sameas that of PEwhile


0i$Cal

0i8r0$Cal0d. In

the periodic expression P0, the number of calendars is one less

than that in P, components O01 to O0

k�1, calendars Cal01 to Cal0k�1

and duration remain the same as that of P while components

O0k to O0

n�1 are updated by their corresponding succeeding

components in P and calendars Cal0k to Cal0n�1 are updated by

their corresponding succeeding calendars in P. In the REB, PE is

updated by PE0.

Command C7: Modify_duration_REB_PE_Pexp (a0, b, PE, rnew,

Caldnew)

In this command, the admin role PRE13 modifies the dura-

tion of a periodic expression of the periodic event PE of a

regular role b from r$Cald to rnew$Caldnew.


The periodic event PE(I, P, p:E ) should belong to the REB of the

system, rnew should belong to the set Z and Caldnew should be a

sub-calendar of Cald.


The new periodic event PE0 should be of the form (I, P0, p:E )

whose interval and prioritized event remain the same as that

of PE while the periodic expression is given by

P0 ¼ Pn0i¼1 O

0i$Cal

0i8r0$Cal0d. In the periodic expression PRE14, the

number of calendars, components and calendars remain the

same as that of P while duration r0$Cal0d is updated by

rnew$Caldnew. In the REB, PE is updated by PE0.

Command C8: Modify_priority_REB_PE (a0, b, PE, p0)

In this command, the admin role Sl modifies the priority

value of the periodic event PE of a regular role b from p to p0.The set PRE8 includes the following preconditions for C8:


system and p0 should belong to the set prios, which is a pre-

defined totally ordered set of priorities.


The new periodic event PE0 is of the form (I, P, p0:E ), whose in-

terval and periodic expression remain the same as that of PE

while thepriority isupdatedbyp0. In theREB,PE isupdatedbyPE0.

Command C9: Modify_Interval_REB_PE (a0, b, PE, Inew)

In this command, the admin role a0 modifies the time in-

terval of the periodic event PE of a regular role b from I to Inew.

The set PRE9 includes the following preconditions for C9: The

periodiceventPE (I,P, p:E ) shouldbelongto theREBof thesystem.


The new periodic event PE0 is of the form (Inew, P, p:E ), whose

periodic expression and prioritized event remain the same as

that of PEwhile the interval is updated by Inew. In the REB, PE is

updated by PE0.The above discussed nine commands are summarized in

Table 1 along with their corresponding relations, pre-

conditions and postconditions.

3.2.2. Role trigger modificationThis sub-section presents six commands (C10 to C15) which can

modify the role triggers.

Command C10: Add_event expression_REB_RT (a0, b, RT, Enew)

In this command, the admin role a0 adds a new event

expression Enew to the role trigger RT of a regular role b.


The role trigger RT (E1, E2,..., Ex,S1,S2,...,Sy / p: E after Dt)

should belong to the REB of the system.


The new role trigger RT0 is of the form E01;E

02..;

E0xþ1;S

01;S

02;..S0y/p0 : E after Dt0. In RT0, the number of event

expressions is onemore than that in RT. Event expressions E01 to

E0x and role status expression S01 to S0y, delay expression, priori-

tized event and the number of role status expressions remain

thesameas thatofRTwhileE0xþ1 isupdatedbyEnew. In theREB,RT

is updated by RT0.

Command C11: Delete_event expression_REB_RT (a0, b, RT, k)

In this command, the admin role a0 deletes an event

expression (Ek) from the role trigger RT of a regular role b.



should belong to the REB of the system and k should lie in the

range (1, x), where x is the number of event expressions in role

trigger RT.

The set POST11 includes the following postconditions for

C11: The new role trigger RT0 is of the form

E01;E

02..;E0

x�1;S01; S

02;..S0y/p0 : E after Dt0. In RT0, the number




of event expressions is one less than that in RT. The delay

expression, prioritized event, role status expressions, event

expressions E01 to E0

k�1 and the number of role status expres-

sions remain the same as that of RT while E0k to E0

x�1 are

updated by their corresponding succeeding event expressions

in RT. In the REB, RT is updated by RT0.

Command C12: Add_role status expression_REB_RT (a0, b, RT,Snew)

In this command, the admin role a0 adds a new role status

expression Snew to the role trigger RT of a regular role b.






E01;E

02..;E0

x;S01; S

02;..S0yþ1/p0 : E after Dt0. In RT0, the number

of role status expressions is one more than that in RT. The

event expressions E01 to E0

x, role status expressions S01 to S0y,prioritized event, delay expression and the number of event

expressions remain the same as that of RT while S0yþ1 is

updated by Snew. In the REB, RT is updated by RT0.

CommandC13:Delete_rolestatusexpression_REB_RT(a0, b,RT,k)

In this command, the admin role a0 deletes a role status

expression (Sk) from the role trigger RT of a regular role b.

ThesetPRE13 includes the followingpreconditions forC13: The

role trigger RT (E1, E2,..., Ex,S1,S2,...,Sy/ p: E afterDt) should

belong to theREBof the systemand k should lie in the range (1, y),

wherey is thenumberof rolestatusexpressions inrole triggerRT.



E01;E

02..;E0

x;S01; S

02;..S0y�1/p0 : E after Dt0. In RT0, the number

of role status expressions is one less than that in RT. The delay

expression, prioritized event, event expressions, role status

expressions S01 to S0k�1 and the number of event expressions

remain the same as that of RT while S0k to S0y�1 are updated by

their corresponding succeeding role status expressions in RT.

In the REB, RT is updated by RT0.

Command C14: Modify_priority_REB_RT (a0, b, RT, p0)

In this command, the admin role a0 modifies priority value

of the role trigger RT of a regular role b from p to p0.The set PRE14 includes the following preconditions for C14:


should belong to the REB of the system and p0 should belong to

the set prios.



E01;E

02..;E0

x;S01; S

02;..S0y/p0 : E after Dt0. In RT0, the role status

expressions, event expressions and the delay expression

remain the same as that of RT while priority of the prioritized

event is updated by p0. In the REB, RT is updated by RT0.

Command C15: Modify_delay_REB_RT (a0, b, RT, t0)

In this command, the admin role a0 modifies the delay

value of the role trigger RT of a regular role b from t to t0.






E01;E

02..;E0

x; S01; S

02;..S0y/p0 : E after Dt0. In RT0, the role status

expressions, event expressions and prioritized event expres-

sion remain the same as that of RT while delay expression is

updated by t0. In the REB, RT should be updated by RT0.The six commands presented in this sub-section are

summarized in Table 2 along with their corresponding re-

lations, preconditions and postconditions.

3.2.3. Addition of new members to REBWedescribe two administrative commands (C16 and C17) listed

in Table 3 to handle addition of new periodic events and role

triggers to REB.

Command C16: Add_PE (a0, b, PEnew)

In this command, the admin role a0 defines a new periodic

event PEnew for a regular role b and adds it to the REB.


PEnew should be of the form (I, P, p:E ).


C16: The number of periodic events present in the REB is

incremented by one. PEnew is added to the REB.

Command C17: Add_RT (a0, b, RTnew)

In this command, the admin role a0 defines a new role

trigger RTnew for a regular role b and adds it to the REB.


RTnew should be of the form (E1, E2,..., Ex,S1,S2,...,Sy / p: E

after Dt).


C17: The number of role triggers present in the REB is incre-

mented by one. RTnew is added to the REB.

3.2.4. Deletion of members from REBIn this sub-section, only one command is discussed for dele-

tion of role triggers as deletion of periodic events can be

handled by command C7 by updating the duration of periodic

event to value zero.

Command C18: Delete_RT (a0, b, RT )

In this command, theadmin rolea0 deletesa role triggerRTof

a regular roleb fromtheREB.ThesetPRE18 includes the following

preconditions forC18:RT should belong to theREBof the system.


C18: RT should be removed from the REB and the number of

role triggers present in the REB is decremented by one.

Command C18 is summarized in Table 4 along with its corre-

sponding relation, preconditions and postconditions.

4. Illustrative example

We now consider an illustrative example using the regular

role hierarchy and the administrative role hierarchy shown in



Fig. 4 e Administrative role hierarchy.


Figs. 3 and 4, respectively. In Fig. 3, Director is the senior most

role and Employee is the junior most role. Similarly in Fig. 4,

CSO (Chief Security Officer) is the senior most role while MSO

(Medical Security Officer) and SSO (Staff Security Officer) are

the junior most roles. DSO (Department Security Officer) is

junior to CSO and senior to MSO and SSO.

Members of administrative roles can change the REB of the

system by executing the administrative commands. They are,

however, only authorized to modify the REB entries of a

certain range of roles in the regular role hierarchy. We denote

these ranges as REB_effective ranges. Each administrative role a

has its own REB_effective range. In Table 5, we present a

possible set of REB_effective ranges for the four administrative

roles shown in Fig. 4. It may be noted that an administrative

role may have more than one REB_effective ranges. For

example, while REB_effective range of CSO is [D, E], that of

DSO includes two REB_effective ranges, [MO, E] and [HN, E].

Thus, REB_effective range of CSO covers the REB_effective

ranges of DSO, which is consistent with the administrative

role hierarchy shown in Fig. 4. In general, if an administrative

role p can change the REB entries of a regular role which lies in

the range q, then its senior role can alsomake similar changes.

In order to illustrate how the commands can be used by

administrative roles to change the REBs of a system, we

consider sample entries in the REB for some of the roles as

shown in Fig. 5.We next consider execution of all the eighteen

commands by passing actual parameters.

The first seven examples show how the periodic expres-

sion of a periodic event of an REB can bemodified by execution

of commandsC1eC7 one by one. The changed REB at the end of

execution of each of the seven commands are shown in

Fig. 6(a)e(g).

Example 1: Modify_REB_PE_P_O1 ( DSO, MD, PE1, years, all,

{1,2,4,7,9})

Thismeans that a user belonging to the administrative role

DSOwants to change componentO1 of the periodic expression

of the periodic event PE1 of the regular roleMD. The new value

for O1 will be {1,2,4,7,9}. In order to update O1, it is required to

add a new calendar Calnew with component Onew as the first

calendar to the periodic expression of the periodic event. The

value of Calnew is years and value of its associated component

is all.

Fig. 3 e Regular role hierarchy.

From Table 5 and Fig. 3, it is seen that DSO is authorized to

modify the REB entry of MD. From Fig. 5, it is seen that PE1belongs to the REB. The first calendar of periodic expression of

the periodic event PE1 is months which is a sub-calendar of

Calnew and value of Onew is all. {1, 2, 4, 7, 9} belongs to 2Z. All the

preconditions specified in Table 1 for command C1 are thus

satisfied. Hence, command execution proceeds. After suc-

cessful execution of the command, the postconditions must

hold: PE1 should be replaced by PE01 in the REB, where PE0

1: ([01/

01/2012e01/01/2020], all.years þ {1, 2, 4, 7,

9}.months þ {1,2,..,30}.days 8 8.hours, H: enable MD). The

updated periodic event is shown as the first entry in Fig. 6(a).

Example 2: Modify_REB_PE_P_comporange (DSO, MD, PE1, 3,

{1, 2, 3, 4, 5})


DSO wants to change a component of the periodic expression

of the periodic event PE1 of the regular role MD. The index of

the component to be modified is 3. The new value for the

component will be {1, 2, 3, 4, 5}.


modify the REB entry of MD. From Fig. 6(a), it is seen that PE1belongs to the REB and the number of calendars n in PE1 is 3.

The index of the component to be modified thus lies in the

range 2 to n. {1, 2, 3, 4, 5} belongs to 2Z. All the preconditions

specified in Table 1 for command C2 are satisfied. Hence,

command execution proceeds. After successful execution of

the command, the postconditions must hold: PE1 should be

replaced by PE01 in the REB, where PE0

1: ([01/01/2012e01/01/

2020], all.years þ {1, 2, 4, 7, 9}.months þ {1, 2, 3, 4,

5}.days 8 8.hours, H: enable MD). The updated periodic event

is shown as the first entry in Fig. 6(b).

Example 3: AddCal_REB_PE_P_Calrange (DSO, MD, PE1,

3, weeks, all)


DSO wants to add a new calendar (weeks) between Cal2 and

Cal3 of the periodic expression of the periodic event PE1 of the

Table 5 e REB_effective ranges of administrative roles.

Admin Role REB_effective Range

CSO [D, E]

DSO [MO, E] W [HN, E]

MSO [MO, CD]

SSO [HN, CD]



Fig. 5 e Sample entries in an REB for some of the roles of

Fig. 3.


regular role MD. The value for the component of the new

calendar will be all.

From Table 5 and Fig. 3, it is seen that DSO is authorized

to modify the REB entry of MD. From Fig. 6(b), it is seen that

PE1 belongs to the REB and the number of calendars n in PE1is 3. The index before which the new calendar will be added

thus lies in the range 2 to n. In the periodic expression of the

periodic event PE1, the value of Cal2 is months and Cal3 is

days. Hence, Calnew is a sub-calendar of Cal2 and Cal3 is

a sub-calendar of Calnew. The value for the component of

the new calendar belongs to the set 2ZWall. All the

preconditions specified in Table 1 for command C3 are

satisfied. Hence, command execution proceeds. After

Fig. 6 e Illustrative examples for commands that modify the pe

Updated REB is shown after (a) Modification of component O1, (b

calendar between any two immediate sub-calendars, (d) Additio

first calendar, (f) Deletion of a calendar (except the first calenda

successful execution of the command, the postconditions

must hold: PE1 should be replaced by PE01 in the REB, where

PE01: ([01/01/2012e01/01/2020], all.years þ {1, 2, 4, 7,

9}.months þ all.weeks þ {1, 2, 3, 4, 5}.days 8 8.hours, H:

enable MD). The updated periodic event is shown as the first

entry in Fig. 6(c).

Example 4: AddCal_REB_PE_P_Caln (DSO, MD, PE1, hours, 9)


DSO wants to add a new calendar (hours) after the last cal-

endar of the periodic expression of the periodic event PE1 of

the regular role MD. The value for the component of the new

calendar will be 9.


modify the REB entry of MD. From Fig. 6(c), it is seen that PE1belongs to the REB and the number of calendars n in PE1 is 4. In

the periodic expression of the periodic event PE1, the value of

Caln is days and Cald is hours. Hence, Calnew is a sub-calendar of

Caln and Cald is a sub-calendar of Calnew. The value for the

component of the new calendar belongs to set 2ZWall. All the

riodic expression of the periodic event of a regular role.

) Modification of a component (except O1), (c) Addition of a

n of a calendar beyond the last calendar, (e) Deletion of the

r), (g) Modification of the duration.



Fig. 7 e Updated REB after modification of priority of a

periodic event.


preconditions specified in Table 1 for command C4 are thus

satisfied. Hence, command execution proceeds. After success-

ful execution of the command, the postconditions must hold:

PE1 should be replaced by PE01 in the REB, where PE01: ([01/01/

2012e01/01/2020], all.years þ {1, 2, 4, 7, 9}.months þall.weeks þ {1, 2, 3, 4, 5}.days þ {9}.hours 8 8.hours, H: enable

MD). The updated periodic event is shown as the first entry in

Fig. 6(d).

Example 5: DeleteCal_REB_PE_P_Cal1 (DSO, MD, PE1)


DSO wants to delete calendar Cal1 from the periodic expres-

sion of the periodic event PE1 of the regular role MD.


modify the REB entry of MD. From Fig. 6(d), it is seen that PE1belongs to the REB and the number of calendars n in PE1 is 5

which is greater than 2. All the preconditions specified in

Table 1 for command C5 are thus satisfied. Hence, command

execution proceeds. After successful execution of the com-

mand, the postconditions must hold: PE1 should be replaced

by PE01 in the REB, where PE0

1: ([01/01/2012e01/01/2020],

all.months þ {1, 2, 3, 4, 5}.days þ all.weeks þ{9}.hours 8 8.hours, H: enable MD). The updated periodic

event is shown as the first entry in Fig. 6(e).

Example 6: DeleteCal_REB_PE_P_Calrange (DSO, MD, PE1,2)


DSO wants to delete calendar Cal2 from the periodic expres-

sion of the periodic event PE1 of the regular role MD.


modify the REB entry of MD. From Fig. 6(e), it is seen that PE1belongs to the REB and the number of calendars n in PE1 is 4.

The index of the calendar to be deleted, therefore, lies in the

range 2 to n. All the preconditions specified in Table 1 for

command C6 are thus satisfied. Hence, command execution

proceeds. After successful execution of the command, the

postconditionsmust hold: PE1 should be replaced by PE01 in the

REB, where PE01: ([01/01/2012e01/01/2020], all.monthsþ {1, 2, 3,

4, 5}.days þ {9}.hours 8 8.hours, H: enable MD). The updated

periodic event is shown as the first entry in Fig. 6(f).

Example 7: Modify_duration_REB_PE_P (DSO, MD, PE1, 10,

hours)


DSO wants to modify duration of the periodic expression of

the periodic event PE1 of the regular role MD. The new value

for duration will be 10.hours. Here, rnew is 10 and Caldnew is

hours.


modify the REB entry of MD. From Fig. 6(f), it is seen that PE1belongs to the REB. The new value for r belongs to the set Z and

Caldnew is a sub-calendar of Cald. All the preconditions speci-

fied in Table 1 for command C7 are thus satisfied. Hence,

command execution proceeds. After successful execution of

the command, the postconditions must hold: PE1 should be

replaced by PE01 in the REB, where PE0

1: ([01/01/2012e01/01/

2020], all.months þ {1, 2, 3, 4, 5}.days þ {9}.hours

8 10.hours, H: enable MD). The updated periodic event is

shown as the first entry in Fig. 6(g).

We next present an example that shows how the priority of

a periodic event of an REB can be modified. Here, we assume

that the set of priorities prios has the following elements: VL, L,

H and VH.

Example 8: Modify_priority_REB_PE (DSO, MD, PE1, VH)


DSO wants to modify the priority of the periodic event PE1 of

the regular role MD. The new value for priority will be VH.


modify the REB entry of MD. From Fig. 6(g), it is seen that PE1belongs to the REB. The new value for priority belongs to the

set prios. All the preconditions specified in Table 1 for com-

mand C8 are thus satisfied. Hence, command execution pro-

ceeds. After successful execution of the command, the



4, 5}.daysþ {9}.hours8 10.hours, VH: enableMD). The updated

periodic event is shown as the first entry in Fig. 7.

The following example shows how the interval of a peri-

odic event of an REB can be modified.

Example 9: Modify_Interval_REB_PE (DSO, MD, PE1, [01/01/

2012e31/12/2020])


DSOwants to modify the interval associated with the periodic

event PE1 of the regular role MD. The new value for interval

will be [01/01e31/12].


modify the REB entry of MD. From Fig. 7, it is seen that PE1belongs to the REB. The precondition specified in Table 1 for

command C9 is thus satisfied. Hence, command execution




4, 5}.daysþ {9}.hours8 10.hours, VH: enableMD). The updated

periodic event is shown as the first entry in Fig. 8.

The next six examples show how a role trigger can be

modified using the commands C10eC15.

Example 10: Add_event-expression_REB_RT (DSO, P, RT1,

enable MS)



Fig. 8 e Updated REB after modification of interval of a

periodic event.



DSOwants to add an event expression to the role trigger RT1 of

the regular role P. The new event expression to be added will

be enable MS.


modify the REB entry of P. From Fig. 8, it is seen that RT1 be-

longs to the REB. The precondition specified in Table 2 for



postconditionsmust hold: RT1 should be replaced by RT01 in the

REB, where RT01: enable MO, enable MS, enabled MD / VL:

enable P after 1. The updated role trigger is shown as the

second entry in Fig. 9(a).

Example 11: Delete_event-expression_REB_RT (DSO, P, RT1, 1)

Fig. 9 e Illustrative examples for commands that modify role tr

expression, (b) Deletion of an event expression, (c) Addition of

expression, (e) Modification of priority, (f) Modification of delay


DSO wants to delete an event expression from the role trigger

RT1 of the regular role P. The index of the event expression to

be deleted is 1.


modify the REB entry of P. From Fig. 9(a), it is seen that RT1

belongs to the REB and the number of event expressions (x) in

RT1 is 2. The index of the event expression to be deleted lies in

the range 1 to x. All the preconditions specified in Table 2 for

command C11 are thus satisfied. Hence, command execution



REB, where RT01: enableMS, enabledMD/VL: enable P after 1.

The updated role trigger is shown as the second entry in

Fig. 9(b).

Example 12: Add_role-status-expression_REB_RT (DSO, P, RT1,

:enabled N)


DSO wants to add a role status expression to the role trigger

RT1 of the regular role P. The new role status expression to be

added will be :enabled N.


modify the REB entry of P. From Fig. 9(b), it is seen that RT1

belongs to the REB. The precondition specified in Table 2 for




iggers. Updated REB is shown after (a) Addition of an event

a role status expression, (d) Deletion of a role status

.




REB, where RT01: enable MS, enabled MD, :enabled N / VL:

enable P after 1. The updated role trigger is shown as the

second entry in Fig. 9(c).

Example 13: Delete_role-status-expression_REB_RT (DSO, P,

RT1, 1)


DSO wants to delete a role status expression from the role

trigger RT1 of the regular role P. The index of the role status

expression to be deleted is 1.


modify the REB entry of P. From Fig. 9(c), it is seen that RT1

belongs to the REB and the number of role status expressions

( y) in RT1 is 2. The index of the role status expression to be

deleted lies in the range 1 to y. All the preconditions specified

in Table 2 for command C13 are thus satisfied. Hence, com-

mand execution proceeds. After successful execution of the

command, the postconditions must hold: RT1 should be

replaced by RT01 in the REB, where RT0

1: enable MS, :enabledN / VL: enable P after 1. The updated role trigger is shown as

the second entry in Fig. 9(d).

Example 14: Modify_priority_REB_RT (DSO, P, RT1, L)


DSO wants to change the priority value of the role trigger RT1

of the regular role P. The new value for the priority will be L.


modify the REB entry of P. From Fig. 9(d), it is seen that RT1

belongs to the REB and the new priority value belongs to the

set prios. All the preconditions specified in Table 2 for com-

mand C14 are thus satisfied. Hence, command execution pro-

ceeds. After successful execution of the command, the


REB, where RT01: enable MS, :enabled N / L: enable P after 1.

The updated role trigger is shown as the last entry in Fig. 9(e).

Example 15: Modify_delay_REB_RT (DSO, P, RT1, 3)

Fig. 10 e Illustrative examples for commands that add new me

periodic event, (b) Addition of a role trigger.


DSO wants to change the delay value of the role trigger RT1 of

the regular role P. The new value for the delay will be 3.


modify the REB entry of P. From Fig. 9(e), it is seen that RT1





REB, where RT01: enable MS, :enabled N / L: enable P after 3.

The updated role trigger is shown as the last entry in Fig. 9(f).

The next two examples show how a new periodic event

and a new role trigger can be added to an REB.

Example 16: Add_PE (DSO, MO, ([21/12/2011e31/12/2025],

all.years þ all.months þ all.weeks þ {2, 3, 4, 5,

6}.days þ {10}.hours 8 8.hours, VH: enable MO))


DSOwants to add a new periodic event for the regular roleMO.

The new periodic event will be given by the following

expression ([21/12/2011e31/12/2025], all.years þ all.months þall.weeks þ {2, 3, 4, 5, 6}.days þ {10}.hours 8 8.hours, VH:

enable MO).


add a newperiodic event for regular roleMO. The newperiodic

event is of the form (I, P, p:E ). The precondition specified in

Table 3 for command C16 is thus satisfied. Hence, execution of

the command proceeds. After successful execution of the

command, the postconditions must hold: a new periodic

event PE2 for role MO should be added in the REB, where PE2:

([21/12/2011e31/12/2025],

all.years þ all.months þ all.weeks þ {2, 3, 4, 5,

6}.days þ {10}.hours 8 8.hours, VH: enable MO). This new

periodic event is shown as the second entry in Fig. 10(a).

Example 17: Add_RT (DSO, MS, (enable MO, enabled MD / H:

enable MS after 3))


DSO wants to add a new role trigger for the regular role MS.

mbers to REB. Updated REB is shown after (a) Addition of a




The new role trigger will be given by the following expression

(enable MO, enabled MD / H: enable MS after 3).


add a new role trigger for the regular role MS. The new role

trigger is of the form (E1, E2,..., Ex,S1,S2,...,Sy / p: E after

Dt). The precondition specified in Table 3 for command C17 is

thus satisfied. Hence, execution of the command proceeds.

After successful execution of the command, the post-

conditionsmust hold: a new role trigger RT2 for roleMS should

be added in the REB, where RT2: (enable MO, enabled MD/H:

enable MS after 3). This new role trigger is shown as the last

entry in Fig. 10(b).

The final example shows deletion of a role trigger from an

REB.

Example 18: Delete_RT (DSO, P, RT1)


DSO wants to delete the role trigger RT1 of the regular role P

from the REB of the system.


modify the REB entry of P. From Fig. 10(b), it is seen that RT1




postconditions must hold: the role trigger RT1 should be

deleted from the REB of the system. It is seen in Fig. 11 that RT1

has been removed from the REB.

Starting from the initial REB shown in Fig. 5, after suc-

cessful execution of the eighteen commands mentioned

above, the updated REB will be as shown in Fig. 11.

5. Related work

Over the last decade and a half, Role Based Access Control

(RBAC) (Sandhu et al., 1996) has emerged as the de facto stan-

dard for access control with applications in operating sys-

tems, databases and various business applications. RBAC

deployment has been reported even in large organizations

(Schaad et al., 2001). A user who is assigned to a role in RBAC

gets the permissions associated with that role at any point of

time. In order to capture time varying nature of permission

availability to users, a temporal extension of RBAC named as

TRBAC has recently been proposed (Bertino et al., 2001).

Fig. 11 e Updated REB after deletion of a role trigger.

TRBAC includes a Role Enabling Base (REB) for defining peri-

odic role enabling and disabling expressed as periodic events

with temporal dependencies among roles specified as role

triggers. Users can get permissions through their assigned

roles only during the time intervals when the role is enabled

as specified in the REB.

Besides TRBAC, other temporal access control models have

also been developed like GTRBAC (Generalized Temporal Role

Based Access Control) (Joshi et al., 2005), which defines tem-

poral constraints on roles, user-role assignment, permission-

role assignment, role activation, constraint enabling, run-time

requests and role triggers. In order to provide an effective

mechanism for the enforcement of access control policies

across distributed domains, X-GTRBAC, an XML-based

GTRBAC policy specification language, has been proposed in

(Bhatti et al., 2005). This specification language is based on the

GTRBAC model and incorporates content as well as context-

aware dynamic access control requirements of an enterprise.

Along with the user level RBAC model, administrative

models have also been proposed for RBAC that manage

administering of roles using RBAC itself. ARBAC97 (Sandhu

et al., 1999), one of the first such models, includes URA97

which controls user to role assignment, PRA97 which controls

permission to role assignment and RRA97 which controls role

to role assignment. ARBAC99 (Sandhu and Munawer, 1999)

adds a few extra features to URA and PRA while RRA is left

unchanged. It extends ARBAC97 by incorporating the concept

of mobile and immobile users and permissions in URA and

PRA models. A user’s membership in a role is considered

mobile if he can use the permission associated with this role

and this membership can be used by the administrative roles

to assign some other roles to the user. On the other hand, role

membership of an immobile user cannot be used by admin-

istrative roles for re-assigning him to other roles. He can

merely use the permissions of the assigned role. Mobile and

immobile permissions are similarly defined. ARBAC02

(Sandhu and Oh, 2002) considers the organizational structure

as the basis for user and permission pools, which are inde-

pendent of roles and role hierarchies. They also suggest a

bottom-up approach for permission to role assignment. The

same notations can_assign, can_revoke, can_assignp and can_-

revokep as those used by ARBAC97 described in Section 2.3 are

adopted by the model for user-role assignment and

permission-role assignment. The notion of prerequisite roles

is replaced by that of user organization structure and

permission organization structure in URA02 and PRA02,

respectively.

Development of administrative models has facilitated

organization-level deployment of RBAC systems. The admin-

istrative models also serve as the basis for security analysis of

RBAC. Both Li and Tripunitara (Li and Tripunitara, 2006) and

Jha et al. (Jha et al., 2008) make use of the relations defined in

URA97. A comparison between the use of model checking and

first order logic programming for the security analysis of RBAC

has been done in (Jha et al., 2008). It is concluded that model

checking is a promising approach in this context.

While security analysis of RBAC has been done based on

the administrative models, use of formal models for TRBAC

security analysis is yet to be reported. Mondal et al. (Mondal

and Sural, 2008; Mondal et al., 2009) use timed automata for




modeling TRBAC and GTRBAC systems. However, they

consider only a fixed set of pre-defined rules for state transi-

tions. Uzun et al. (Uzun et al., 2012) propose some adminis-

trative functions for temporal RBAC to perform security

analysis. Specifically, they define a schedule to represent pe-

riodic time and assume that the system is periodic, i.e., the

schedules repeat themselves after a quantum of time TMAx.

However, this assumption may not hold for some roles in a

system since schedules associated with the roles may repeat

themselves after different time intervals. Also, a schedule is a

simplified representation of calendar, which is central to the

representation of the temporal component in the TRBAC

model (Bertino et al., 2001). Thus, the administrative model in

(Uzun et al., 2012) is only an abstract model and does not

capture the mechanisms by which role enabling conditions

can be changed. Moreover, their temporal RBAC security

analysis queries cannot handle additional components like

role triggers and periodic events.

Thus, in contrast to RBAC, both practical deployment as

well as formal security analysis of TRBAC systems are

restricted due to non-availability of a corresponding admin-

istrative model. Although the proposed AMTRAC model uses

existing components of ARBAC97 for managing the non-

temporal aspects of TRBAC, a completely new set of eigh-

teen administrative relations has been defined by which

administrative roles can manage the temporal constraints

imposed on roles.

It may, however, be noted that, X-GTRBAC Admin - an

administrative model for the X-GTRBAC framework, has been

proposed in (Bhatti et al., 2004). This addresses the adminis-

tration problem for enterprise-wide access control including

authorization management for users and resources within a

single domain as well as conflict resolution among access

control policies of multiple domains. However, it does not

focus on the administration of periodic role enabling and

disabling conditions, i.e., which administrative role possesses

the authority to modify the periodic role enabling and

disabling conditions of which regular role. It also does not

explain the variousways bywhichmembers of administrative

roles can actually modify the periodic events and role triggers

of regular roles under the control of administrative policy. It

may be noted that, the X-GTRBAC Admin model defines two

administrative relations can_enable and can_disable which

manage the set of current enabled regular roles at an abstract

level and does not describe how actually the enabling and

disabling conditions of regular roles can be changed. In

contrast, AMTRAC manages all the relevant components for

enabling and disabling of roles as well as temporal de-

pendencies among them.

6. Conclusion

Although administrative models for RBAC exist, no work has

so far been done on the development of administrative

models for TRBAC. AMTRAC as proposed in this paper, is the

first administrativemodel for TRBAC. It includes a broad range

of relations which control modifications made in the various

components of TRBAC, namely, UA, PA, RH and REB through

administrative roles. AMTRAC can be used for two major

purposes, namely, real-life deployment of TRBAC systems and

security analysis of TRBAC. Although decentralized TRBAC

administration enhances flexibility, it also results in reduced

organizational control over its resources. In order to provide

decentralized administration and central control over re-

sources there is a need for formal analysis of security prop-

erties of TRBAC systems. Given a set of access control policies,

a general safety requirement is to determine whether a

desirable property is satisfied in all reachable states. Such an

analysis requires formal verification of access control policies.

Although formal analysis has been done on traditional RBAC

(Li and Tripunitara, 2006; Jha et al., 2008) and to a certain

extent for TRBAC (Uzun et al., 2012; Mondal and Sural, 2008)

and GTRBAC (Mondal et al., 2009), none of them uses a formal

administrative model. Use of AMTRAC will formalize these

types of analysis methodologies.

Similar to AMTRAC as proposed in this paper, adminis-

trative models need to be built for Geo-RBAC, spatio-temporal

RBAC and GTRBAC for their practical implementation as well

as for performing formal security analysis. The administrative

model for spatial extensions of RBAC like Geo-RBAC can be

built by developing components that can manage the spatial

domain associated with various roles. In addition, spatial role

hierarchies and use of spatial constructs for defining admin-

istrative policies would form an important component of such

models. AMTRAC can also be extended to administer GTRBAC

by introducing new administrative features that can manage

the additional constraints defined in GTRBAC like role acti-

vation constraints, duration constraints, etc. We plan to work

on this in future.

r e f e r e n c e s

Aich S, Sural S, Majumdar AK. STARBAC: spatiotemporal rolebased access control. In: OTM’07 Proc. of the 2007 OTMConfederated international conference on meaningfulinternet systems: CoopIS, DOA, ODBASE, GADA, and IS, Vol.Part II; 2007. p. 1567e82.

Aich S, Mondal S, Sural S, Majumdar AK. Role based accesscontrol with spatiotemporal context for mobile applications.Transactions on Computational Science 2009;IV:177e99.

Ammann P, Sandhu RS. Safety analysis for the extendedschematic protection model. In: Proc. IEEE symposium onsecurity and privacy 1991. p. 87e97.

Bertino E, Bonatti P, Ferrari E. TRBAC: a temporal role basedaccess control model. ACM Transactions on Information andSystem Security 2001:191e233.

Bertino E, Catania B, Damiani ML, Perlasca P. GEO-RBAC: aspatially aware RBAC. ACM Transactions on Information andSystem Security 2007:29e37.

Bhatti R, Ghafoor A, Bertino E, Joshi JBD. X-GTRBAC admin: adecentralized administration model for enterprise wideaccess control. In: SACMAT 2004, Proc. of the 9th ACMsymposium on access control models and technologies 2004.p. 78e86.

Bhatti R, Ghafoor A, Bertino E, Joshi JBD. X-GTRBAC: an XML-based policy specification framework and architecture forenterprise-wide access control. ACM Transactions onInformation and System Security (TISSEC) 2005:187e227.

Harrison MA, Ruzzo WL, Ullman JD. On protection in operatingsystems. Communications of the ACM 1976:461e71.

http://refhub.elsevier.com/S0167-4048(13)00096-5/sref1







































Jha S, Li N, Tripunitara M, Wang Q, Winsborough W. Towardsformal verification of role-based access control policies. IEEETransactions on Dependable and Secure Computing2008:242e55.

Jin X, Krishnan R, Sandhu RS. A unified attribute-based accesscontrol model covering DAC, MAC and RBAC. In: DBSec’12Proc. of the 26th Annual IFIP WG 11.3 conference on data andapplications security and privacy 2012. p. 41e55.

Joshi JBD, Bertino E, Latif U, Ghafoor A. A generalized temporalrole-based access control model. IEEE Transactions onKnowledge and Data Engineering 2005:4e23.

Li N, Tripunitara M. Security analysis in role-based access control.ACM Transactions on Information and System Security2006:391e420.

Mondal S, Sural S. Security analysis of temporal-RBAC usingtimed automata. In: Proc. of the 4th international conferenceon information assurance and security, (IAS08). Naples, Italy:IEEE Computer Society Press; 2008. p. 37e40.

Mondal S, Sural S, Atluri V. Towards formal security analysis ofGTRBAC using timed automata. In: Proc. of the 14th ACMsymposium on access control models and technologies(SACMAT) 2009. p. 33e42.

Osborn S. Mandatory access control and role-based access controlrevisited. In: RBAC ’97 Proc. of the 2nd ACM workshop on role-based access control 1997. p. 31e40.

Osborn S, Sandhu R, Munawer Q. Configuring role-based accesscontrol to enforce mandatory and discretionary access controlpolicies. In: ACM transactions on information and systemsecurity (TISSEC) 2000. p. 85e106.

Ray I, Kumar M, Yu L. LRBAC: a location-aware role-based accesscontrol model. In: Proc. of the 2nd international conference oninformation systems security 2006. p. 147e61.

Sandhu RS. The schematic protection model: its definition andanalysis for acyclic attenuating schemes. Journal of the ACM1988:404e32.

Sandhu RS. The typed access matrix model. In: Proc. IEEEsymposium on research in security and privacy 1992.p. 122e36.

Sandhu R, Munawer Q. The ARBAC99 model for administration ofroles. In: ACSAC 1999, Proc. of the 15th Annual computersecurity applications conference 1999. p. 229e38.

Sandhu R, Oh S. A model for role administration usingorganization structure. In: SACMAT 2002, Proc. of the 7th ACMsymposium on access control models and technologies 2002.p. 155e62.

Sandhu R, Coyne E, Feinstein H, Youman C. Role-based accesscontrol models. IEEE Computer 1996:38e47.

Sandhu R, Bhamidipati V, Munawer Q. The ARBAC97 modelfor role-based administration of roles. In: ACMtransactions on information and system security (TISSEC)1999. p. 105e35.

Schaad A, Moffett JD, Jacob J. The role-based access controlsystem of a European bank: a case study and discussion. In:

SACMAT 2002, Proc. of the 6th ACM symposium on accesscontrol models and technologies 2001. p. 3e9.

Synder L. On the synthesis and analysis of protection system. In:SOSP’77 Proc. of the 6th ACM symposium on operatingsystems principles 1977. p. 141e50.

Tripunitara MV, Li N. The foundational work of Harrison-Ruzzo-Ullman revisited. IEEE Transactions on Dependable andSecure Computing 2013:28e39.

Uzun E, Atluri V, Sural S, Vaidya J, Parlato G, Ferrarra AL, et al.Analyzing temporal role based access control models. In:SACMAT 2012, Proc. of the 17th ACM symposium on accesscontrol models and technologies 2012. p. 177e86.

Manisha Sharma is aMasters student at the School of InformationTechnology, IIT Kharagpur, India. She received her Bachelor’s de-gree from the Guru Gobind Singh Indraprastha University, Delhi,India in Information Technology in 2010. Her research interestsinclude access control, security analysis and database systems.

Shamik Sural is a professor at the School of Information Tech-nology, IIT Kharagpur, India. He received the Ph.D. degree fromJadavpur University in 2000. He has served on the Program Com-mittee of many international conferences. He is a senior memberof the IEEE and has served as the Chairman of the IEEE KharagpurSection. He is a recipient of the Alexander von Humboldt Fellow-ship for Experienced Researchers. He has published more thanone hundred and forty research papers in reputed internationaljournals and conferences. His research interests include com-puter security, data mining and multimedia database systems.

Jaideep Vaidya is an associate professor of Computer InformationSystems at Rutgers University. He received the bachelor’s degreein Computer Engineering at the University of Mumbai and mas-ter’s and PhD degrees in Computer Science at Purdue University.His research interests are in privacy, security, data mining, anddata management and he has published more than 90 papers ininternational conferences and journals. He is a recipient of USNational Science Foundation Career Award and a Rutgers Board ofTrustees Research Fellowship for Scholarly Excellence. He is amember of the IEEE Computer Society and a member of the ACM.

Vijayalakshmi Atluri is a professor of computer informationsystems in the MSIS Department, and research director for theCenter for Information Management, Integration and Connectiv-ity at Rutgers University. She is currently a program director at USNational Science Foundation. Her research interests include in-formation security, spatial databases, multimedia and distributedsystems. She has published extensively in premier journals andconferences. She was the recipient of the NSF CAREER Award, andthe Rutgers University Research Award for untenured faculty foroutstanding research contributions. She is a seniormember of theIEEE Computer Society and a member of the ACM.























































































Documents

AMTRAC: An administrative model for temporal role-based access control