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

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

Available online at www.sciencedirect.com

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

AMTRAC: An administrative model for temporal role-based access control Manisha Sharma a, Shamik Sural a,*, Jaideep Vaidya b, Vijayalakshmi Atluri b a b

School of Information Technology, Indian Institute of Technology, Kharagpur, India MSIS Department and CIMIC, Rutgers University, USA

article info

abstract

Article history:

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

Received 21 February 2013

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

Received in revised form

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

13 May 2013

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

Accepted 9 July 2013

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

Keywords:

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

Administrative model

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

Temporal RBAC

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

Role enabling base assignment

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

Administrative command

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

Role hierarchy

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

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 Attribute 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

indirection between users and permissions through roles (Schaad et al., 2001). For certain applications, which need to make access control decisions based on contextual information like location and time, RBAC however is not adequate. To handle such requirements, 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

* Corresponding author. Tel.: þ91 3222 282330. E-mail addresses: [email protected] (M. Sharma), [email protected], [email protected] (S. Sural), [email protected] (J. Vaidya), [email protected] (V. Atluri). 0167-4048/$ e see front matter ª 2013 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.cose.2013.07.005

202

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

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 decentralization of administration, which delegates administrative privileges among various administrative roles as it is overwhelming 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. Development 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 properties using a formal language. A suitable formal analysis

methodology like model checking is then followed for verifying 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 restricts 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 Control). A number of relations are defined in AMTRAC for managing 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,

Fig. 1 e Conceptual diagram for AMTRAC.

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

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 along with their pre and Postconditions that can be used to administer a TRBAC system using AMTRAC. Successful execution of each of these commands requires the administrative user to have requisite permission to execute the command as specified in the abovementioned relations capturing the system administration policies and also the preconditions to be satisfied. On completion of execution, the set of corresponding postconditions should hold for each command. The rest of the paper is organized as follows. Preliminaries 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 understanding 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 subsection gives an overview of the administrative RBAC model on which AMTRAC is based.

2.1.

Role based access control model (RBAC)

RBAC is a model 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.

203

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 periodic time instants. The definition of periodic expressions 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 P ¼ ni¼1 Oi $Cali 8r$Cald where O1 ¼ all, Oi ˛2Z Wfallg, Cali 4 Cali1, 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 periodic expression:

204

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

all:years þ all:months þ all:weeks þ f1; 2; 4g:days þ 10:hours88:hours:

The above periodic expression represents a set of time intervals 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 predefined 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 expression. 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, PRA97permission 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 PRA97 may be open, closed or halfopen. A precondition is a conjunction of literals, where each literal is either in positive form r or in negative form:r, for some 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 to be 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 administrative roles. Can_assign is of the form where a is an administrative role, c is a precondition and b is a role range. The ordered triple represents the fact that members 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 where a is an administrative role and b is a role range. 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_revokep which are similar to Can_assign and Can_revoke respectively. Can_assignp is of the form . 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 regular role fulfills the precondition c. Can_revokep is of the form . 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 , 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 a model that can be used to define policies for administering the various components 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 Temporal 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. 2. 3. 4.

URA (User to role assignment) PRA (Permission to role assignment) RRA (Role to role assignment) REBA (Role Enabling Base Assignment)

User-role assignment is controlled by the relations defined in URA97, Permission-role assignment is controlled by the relations defined in PRA97 while Roleerole assignment is controlled by the relations defined in RRA97. Since these components 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.

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

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

Table 1 e Administrative commands for periodic event modification along with their corresponding relations, preconditions and postconditions. C1 R1 PRE1 POST1

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 commands (denoted by Cis) along with their corresponding relations (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 administrative roles which are authorized to change the periodic enabling and disabling conditions of regular roles and temporal dependencies among regular roles. An instance of this set of relations represents the currently effective administrative policy of the system. Overall, the set of identified administrative 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.

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.

C2 R2 PRE2 POST2

C3 R3 PRE3 POST3

C4 R4 PRE4 POST4

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 y2 respectively 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:

Modification in periodic events

A periodic event of the form (I, P, p:E ) can be modified by changing either the periodic expression, the priority of the prioritized event or the interval. On the basis of these three ways 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

205

C5 R5 PRE5 POST5

C6 R6 PRE6 POST6

C7 R7 PRE7 POST7

C8 R8 PRE8 POST8 C9 R9 PRE9 POST9

Modify_REB_PE_P_O1 (a0 , b, PE, Calnew, Onew, O1new) Can_Modify_REB_PE_P_O1 (a, r) PE ˛ REB, Cal1 4 Calnew, Onew ¼ all, O1new ˛2Z Wfallg P 0 P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d where n0 ¼ nþ1, O02 ¼ O1new ; Cal02 ¼ Cal1 ; O0kþ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 Modify_REB_PE_P_comporange (a0 , b, PE, k, Onew) Can_Modify_REB_PE_P_comporange (a, r, i, j) PE ˛ REB, 2  i  n, 2  j  n, i  j, i  k  j, Onew ˛2Z Wfallg P 0 P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d where n0 ¼ n, O0l ¼ Ol for l ¼ 1 to k1, O0k ¼ Onew ; O0l ¼ 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 AddCal_REB_PE_P_calrange (a0 , b, PE, k, Calnew, Onew) Can_AddCal_REB_PE_P_calrange (a, r, i, j) PE ˛ REB, 2  i  n, 2  j  n, i  j, i  k  j, Calnew 4Calk1 ; Calk 4Calnew ; Onew ˛2Z Wfallg P 0 P0 ¼ ni¼1 O0i $Cal0i 8r0 $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 ; O0l ¼ Ol , for l ¼ 1 to k1, Cal0l ¼ Call for l ¼ 1 to k1, r0 ¼ r, Cal0d ¼ Cald , PE0 ¼ (I, P0 , p:E), REB ¼ (REB\PE)WPE0 AddCal_REB_PE_P_Caln (a0 , b, PE, Calnew, Onew) Can_AddCal_REB_PE_P_Caln (a, r) PE ˛ REB, Calnew 4 Caln, Cald 4 Calnew, Onew ˛2Z Wfallg P 0 P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d where n0 ¼ n þ 1, 0 Ol ¼ Ol for l ¼ 1 to n, Cal0l ¼ Call for l ¼ 1 to n, O0n0 ¼ Onew ; Cal0n0 ¼ Calnew , r0 ¼ r, Cal0d ¼ Cald , PE0 ¼ (I, P0 , p:E), REB ¼ (REB\PE)WPE0 DeleteCal_REB_PE_P_Cal1 (a0 , b, PE) Can_DeleteCal_REB_PE_P_Cal1 (a, r) PE˛REB, n  2 P 0 P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d where n0 ¼ n1, 0 Ol1 ¼ Ol for l ¼ 3 to n, Cal0l1 ¼ Call for l ¼ 3 to n, O01 ¼ all; Cal01 ¼ Cal2 , r0 ¼ r, Cal0d ¼ Cald , PE0 ¼ (I, P0 , p:E), REB ¼ (REB\PE)WPE0 DeleteCal_REB_PE_P_Calrange (a0 , b, PE, k) Can_DeleteCal_REB_PE_P_Calrange (a, r ,i ,j) PE ˛ REB, 2  i  n, 2  j  n, i  j, i  k  j, n  2 P 0 P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d where n0 ¼ n1, O0l ¼ Ol for l ¼ 1 to k1, Cal0l ¼ Call for l ¼ 1 to k1, O011 ¼ Ol for l ¼ kþ1 to n, Cal011 ¼ Call for l ¼ kþ1 to n, r0 ¼ r, Cal0d ¼ Cald , PE0 ¼ (I, P0 , p:E), REB ¼ (REB\PE)WPE0 Modify_duration_REB_PE_P (a0 , b, PE, rnew, Caldnew) Can_Modify_duration_REB_PE_P (a, r) PE ˛ REB, rnew ˛Z; Caldnew 4Cald P 0 P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d where n0 ¼ n, O0l ¼ Ol for l ¼ 1 to n, Cal0l ¼ Call for l ¼ 1 to n, r0 ¼ rnew, Cal0d ¼ Caldnew , PE0 ¼ (I, P0 , p:E), REB ¼ (REB\PE)WPE0 Modify_priority_REB_PE (a0 , b, PE, p0 ) Can_Modify_priority_REB_PE (a, r) PE ˛ REB, p0 ˛ prios PE0 ¼ (I, P, p0 :E), REB ¼ (REB\PE)WPE0 Modify_Interval_REB_PE (a0 , b, PE, Inew) Can_Modify_Interval_REB_PE (a, r) PE ˛ REB PE0 ¼ (Inew, P, p:E), REB ¼ (REB\PE)WPE0

206

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

Table 2 e Administrative commands for role trigger modification along with their corresponding relations, preconditions and postconditions. C10 R10 PRE10 POST10

C12 R12 PRE12 POST12

C14 R14 PRE14 POST14

Add_event-expression_REB_RT (a0 , b, RT, Enew) Can_Add_event-expression_REB_RT (a, r) RT ˛ REB RT0 ¼ E01 ; E02 ..; E0x0 ; S01 ; S02 ; ..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 Add_role-status-expression_REB_RT (a0 , b, RT, Snew) Can_Add_role-status-expression_REB_RT (a, r) RT ˛ REB RT0 ¼ E01 ; E02 ..; E0x0 ; S01 ; S02 ; ..S0y0 /p0 : E after Dt0 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 Modify_priority_REB_RT (a0 , b, RT, p0 ) Can_Modilfy_priority_REB_RT (a, r) RT ˛ REB, p0 ˛ prios RT0 ¼ E01 ; E02 ..; E0x0 ; S01 ; S02 ; ..S0y0 /p0 : E after Dt0 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

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 modification 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 modification 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  (n1) and 1  j  (n1), where n is the number of

C11 R11 PRE11 POST11

C13 R13 PRE13 POST13

C15 R15 PRE15 POST15

Delete_event-expression_REB_RT (a0 , b, RT, k) Can_Delete_event-expression_REB_RT (a, r) RT ˛ REB, 1  k  x RT0 ¼ E01 ; E02 ..; E0x0 ; S01 ; S02 ; ..S0y0 /p0 : E after Dt0 where x0 ¼ x1, y0 ¼ y, p0 ¼ p, t0 ¼ t, E0l ¼ El for l ¼ 1 to k1, E0l1 ¼ El for l ¼ kþ1 to x, S0l ¼ Sl for l ¼ 1 to y, REB ¼ (REB\RT)WRT0 Delete_role-status-expression_REB_RT (a0 , b, RT, k) Can_Delete_role-status-expression_REB_RT (a, r) RT ˛ REB, 1  k  y RT0 ¼ E01 ; E02 ..; E0x0 ; S01 ; S02 ; ..S0y0 /p0 : E after Dt0 where x0 ¼ x, y0 ¼ y1, p0 ¼ p, t0 ¼ t, E0l ¼ El for l ¼ 1 to x, S0l ¼ Sl for l ¼ 1 to k1, S0l1 ¼ Sl for l ¼ k þ 1 to y, REB ¼ (REB\RT)WRT0 Modify_delay_REB_RT (a0 , b, RT, t0 ) Can_Modify_delay_REB_RT (a, r) RT ˛ REB RT0 ¼ E01 ; E02 ..; E0x0 ; S01 ; S02 ; ..S0y0 /p0 : E after Dt0 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

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 subcalendar 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 calendar 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 periodic 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 periodic event. 3.1.2.

Modification in role triggers

Role triggers can be modified by adding or deleting the event expression, by adding or deleting the role status expression, Table 3 e Administrative commands for addition of new members to REB along with their corresponding relations, preconditions and postconditions. C16 R16 PRE16 POST16 C17 R17 PRE17 POST17

Add_PE (a0 , b, PEnew) Can_Add_PE (a, r) PEnew is of the form (I, P, p:E ) REB ¼ REB W PEnew Add_RT (a0 , b, RTnew) Can_Add_RT (a, r) RTnew is of the form (E1, E2,..., Ex,S1,S2,...,Sy / p: E after Dt) REB ¼ REB W RTnew

Table 4 e Administrative commands for deletion of members from REB along with their corresponding relations, preconditions and postconditions. C18 R18 PRE18 POST18

Delete_RT (a0 , b, RT) Can_Delete_RT (a, r) RT ˛ REB REB ¼ REB\RT

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

207

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 triggers. R10 controls addition of a new event expression to a role trigger. R11 controls deletion of an event expression from a 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 modification of priority and delay expression of a role trigger.

3.1.3.

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. Parameters x1 and x2 of each command denote administrative role Sy/ and role b where a0 ˛AR and b ˛ R.

Addition of new members to REB

Two relations R16 and R17 fall under this section. R16 controls addition of a new periodic event for a role. R17 controls addition of a new role trigger for a role.

3.1.4.

Deletion of members from REB

This 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 conditions: 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

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

208

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

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 algorithm 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 Algorithm 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 subsections.

3.2.1.

Periodic event modification

In this sub-section, we describe nine administrative commands (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 2Z Wfallg. 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 P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d . In the periodic expression P0 , the number of calendars is one more than that in P, the components O03 to O0nþ1 are updated by their corresponding preceding components in P (i.e., O2 to On), the calendars Cal03 to Cal0nþ1 are updated by their corresponding preceding components 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 component associated with the calendar Calk in a periodic expression of the periodic event PE of a regular role b.

The set PRE2 includes the following preconditions for C2: 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 parameters 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 2Z Wfallg. The set POST2 includes the following postconditions for C2: 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 P0 the periodic expression is given by P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d . In the periodic expression P0 , the number of calendars, duration, calendars Cal01 to Cal0n and components O01 to O0n remain the same as that of P except O0k which is updated by Onew. In the REB, 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 Calk1 and Calk in a periodic expression of the periodic event PE of a regular role b. The set PRE3 includes the following preconditions for C3: 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 parameters of relation R2 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, Calnew should be a sub-calendar of Calk1, Calk should be a sub-calendar of Calnew and Onew should belong to the set 2Z Wfallg. The set POST3 includes the following postconditions for C3: 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 P0 the periodic expression is given by P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d . In 0 the periodic expression P , the number of calendars is one more than that in P, calendars Cal0i to Cal0k1 and components O1 to Olþ1 are updated by their corresponding elements in P, components O0kþ1 to Onþ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 Calnew after the calendar Caln in a periodic expression of the periodic event PE of a regular role b. The set PRE4 includes the following preconditions for C4: The periodic event PE (I, P, p:E ) should belong to the REB of the system, Calnew should be a sub-calendar of Caln, Cald should be a sub-calendar of Calnew and Onew should belong to the set 2Z Wfallg. 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 P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d . In the periodic expression P0 , the number of calendars is one more than that in P, calendars Cal01 to Cal0n , components O01 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 .

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

209

Command C5: DeleteCal_REB_PE_Pexp_Cal1 (a0 , b, PE )

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

In this command, the admin role a0 deletes the calendar Cal1 from a periodic expression of the periodic event of a regular role b. The set PRE5 includes the following preconditions for C5: The periodic event PE (I, P, p:E ) should belong to the REB of the system and n  2. The set POST5 includes the following postconditions for C5: 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 P0 the periodic expression is given by P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d . In the periodic expression Caldnew 4 Cald, the number of calendars is reduced by one, the components O02 to O0n1 are updated by their corresponding succeeding components in P, calendars Cal02 to Cal0n1 are updated by their corresponding succeeding calendars in P, O1 is updated by all, Cal1 is updated by Cal2, while duration remains the same as that of P. In the REB, PE is updated by PE0 .

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: The periodic event PE (I, P, p:E ) should belong to the REB of the system and p0 should belong to the set prios, which is a predefined totally ordered set of priorities. The set POST8 includes the following postconditions for C8: The new periodic event PE0 is of the form (I, P, p0 :E ), whose interval and periodic expression remain the same as that of PE while the priority is updated by p0 . 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 from the periodic expression of the periodic event of a regular role b. The set PRE6 includes the following preconditions for C6: 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 parameters of relation R5 such that i and j both lie in range 2 to n, where n is the number of calendars in the periodic expression P, i  j and n  2. The set POST6 includes the following postconditions for C6: 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 P0 the periodic expression is given by P0 ¼ ni¼1 O0i $Cal0i 8r0 $Cal0d . In 0 the periodic expression P , the number of calendars is one less than that in P, components O01 to O0k1 , calendars Cal01 to Cal0k1 and duration remain the same as that of P while components O0k to O0n1 are updated by their corresponding succeeding components in P and calendars Cal0k to Cal0n1 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 duration of a periodic expression of the periodic event PE of a regular role b from r$Cald to rnew$Caldnew. The set PRE7 includes the following preconditions for C7: 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 set POST7 includes the following postconditions for C7: 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 P0 ¼ ni¼1 O0i $Cal0i 8r0 $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 C9: Modify_Interval_REB_PE (a0 , b, PE, Inew) In this command, the admin role a0 modifies the time interval of the periodic event PE of a regular role b from I to Inew. The set PRE9 includes the following preconditions for C9: The periodic event PE (I, P, p:E ) should belong to the REB of the system. The set POST9 includes the following postconditions for C9: 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 PE while 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, preconditions and postconditions.

3.2.2.

Role trigger modification

This 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 set PRE10 includes the following preconditions for C10: The role trigger RT (E1, E2,..., Ex,S1,S2,...,Sy / p: E after Dt) should belong to the REB of the system. The set POST10 includes the following postconditions for C10: The new role trigger RT0 is of the form E01 ; E02 ..; E0xþ1 ; S01 ; S02 ; ..S0y /p0 : E after Dt0 . In RT0 , the number of event expressions is one more than that in RT. Event expressions E01 to E0x and role status expression S01 to S0y , delay expression, prioritized event and the number of role status expressions remain the same as that of RT while E0xþ1 is updated by Enew. In the REB, 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. The set PRE11 includes the following preconditions for C11: The role trigger RT (E1, E2,..., Ex,S1,S2,...,Sy / p: E after Dt) 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 ; E02 ..; E0x1 ; S01 ; S02 ; ..S0y /p0 : E after Dt0 . In RT0 , the number

210

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

of event expressions is one less than that in RT. The delay expression, prioritized event, role status expressions, event expressions E01 to E0k1 and the number of role status expressions remain the same as that of RT while E0k to E0x1 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. The set PRE12 includes the following preconditions for C12: The role trigger RT (E1, E2,..., Ex,S1,S2,...,Sy / p: E after Dt) should belong to the REB of the system. The set POST12 includes the following postconditions for C12: The new role trigger RT0 is of the form E01 ; E02 ..; E0x ; S01 ; S02 ; ..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 E0x , 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 . Command C13: Delete_role status expression_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. The set PRE13 includes the following preconditions for C13: The role trigger RT (E1, E2,..., Ex,S1,S2,...,Sy / p: E after Dt) should belong to the REB of the system and k should lie in the range (1, y), where y is the number of role status expressions in role trigger RT. The set POST13 includes the following postconditions for C13: The new role trigger RT0 is of the form E01 ; E02 ..; E0x ; S01 ; S02 ; ..S0y1 /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 S0k1 and the number of event expressions remain the same as that of RT while S0k to S0y1 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: The role trigger RT (E1, E2,..., Ex,S1,S2,...,Sy / p: E after Dt) should belong to the REB of the system and p0 should belong to the set prios. The set POST14 includes the following postconditions for C14: The new role trigger RT0 is of the form E01 ; E02 ..; E0x ; S01 ; S02 ; ..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 .

The set PRE15 includes the following preconditions for C15: The role trigger RT (E1, E2,..., Ex,S1,S2,...,Sy / p: E after Dt) should belong to the REB of the system. The set POST15 includes the following postconditions for C15: The new role trigger RT0 is of the form E01 ; E02 ..; E0x ; S01 ; S02 ; ..S0y /p0 : E after Dt0 . In RT0 , the role status expressions, event expressions and prioritized event expression 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 relations, preconditions and postconditions.

3.2.3.

Addition of new members to REB

We describe 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. The set PRE16 includes the following preconditions for C16: PEnew should be of the form (I, P, p:E ). The set POST16 includes the following postconditions for 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. The set PRE17 includes the following preconditions for C17: RTnew should be of the form (E1, E2,..., Ex,S1,S2,...,Sy / p: E after Dt). The set POST17 includes the following postconditions for C17: The number of role triggers present in the REB is incremented by one. RTnew is added to the REB.

3.2.4.

Deletion of members from REB

In this sub-section, only one command is discussed for deletion 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, the admin role a0 deletes a role trigger RT of a regular role b from the REB.The set PRE18 includes the following preconditions for C18: RT should belong to the REB of the system. The set POST18 includes the following postconditions for 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 corresponding relation, preconditions and postconditions.

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

4.

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 .

We now consider an illustrative example using the regular role hierarchy and the administrative role hierarchy shown in

Illustrative example

211

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

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 also make 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 expression of a periodic event of an REB can be modified by execution of commands C1eC7 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}) This means that a user belonging to the administrative role DSO wants to change component O1 of the periodic expression of the periodic event PE1 of the regular role MD. 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. 4 e Administrative 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 PE1 belongs 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 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 þ {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}) This means that a user belonging to the administrative role 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}. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of MD. From Fig. 6(a), it is seen that PE1 belongs 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 PE01 : ([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 3, weeks, all)

(DSO, MD,

PE1,

This means that a user belonging to the administrative role 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.

Fig. 3 e Regular role hierarchy.

Admin Role

REB_effective Range

CSO DSO MSO SSO

[D, E] [MO, E] W [HN, E] [MO, CD] [HN, CD]

212

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

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

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)

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 PE1 is 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 2Z Wall. All the preconditions specified in Table 1 for command C3 are satisfied. Hence, command execution proceeds. After

This means that a user belonging to the administrative role DSO wants to add a new calendar (hours) after the last calendar 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. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of MD. From Fig. 6(c), it is seen that PE1 belongs 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 2Z Wall. All the

Fig. 6 e Illustrative examples for commands that modify the periodic expression of the periodic event of a regular role. Updated REB is shown after (a) Modification of component O1, (b) Modification of a component (except O1), (c) Addition of a calendar between any two immediate sub-calendars, (d) Addition of a calendar beyond the last calendar, (e) Deletion of the first calendar, (f) Deletion of a calendar (except the first calendar), (g) Modification of the duration.

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

213

preconditions specified in Table 1 for command C4 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 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).

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 5: DeleteCal_REB_PE_P_Cal1 (DSO, MD, PE1)

This means that a user belonging to the administrative role DSO wants to modify the priority of the periodic event PE1 of the regular role MD. The new value for priority will be VH. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of MD. From Fig. 6(g), it is seen that PE1 belongs to the REB. The new value for priority belongs to the set prios. All the preconditions specified in Table 1 for command C8 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 PE01 : ([01/01/2012e01/01/2020], all.months þ {1, 2, 3, 4, 5}.days þ {9}.hours 8 10.hours, VH: enable MD). The updated periodic event is shown as the first entry in Fig. 7. The following example shows how the interval of a periodic event of an REB can be modified.

This means that a user belonging to the administrative role DSO wants to delete calendar Cal1 from the periodic expression of the periodic event PE1 of the regular role MD. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of MD. From Fig. 6(d), it is seen that PE1 belongs 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 command, the postconditions must 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 þ 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) This means that a user belonging to the administrative role DSO wants to delete calendar Cal2 from the periodic expression of the periodic event PE1 of the regular role MD. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of MD. From Fig. 6(e), it is seen that PE1 belongs 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 postconditions must 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) This means that a user belonging to the administrative role 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. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of MD. From Fig. 6(f), it is seen that PE1 belongs to the REB. The new value for r belongs to the set Z and Caldnew is a sub-calendar of Cald. All the preconditions specified 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 PE01 : ([01/01/2012e01/01/ 2020], all.months þ {1, 2, 3, 4, 5}.days þ {9}.hours

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

Example 9: Modify_Interval_REB_PE (DSO, MD, PE1, [01/01/ 2012e31/12/2020]) This means that a user belonging to the administrative role DSO wants 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]. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of MD. From Fig. 7, it is seen that PE1 belongs to the REB. The precondition specified in Table 1 for command C9 is 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 PE01 : ([01/01/2012e31/12/2020], all.months þ {1, 2, 3, 4, 5}.days þ {9}.hours 8 10.hours, VH: enable MD). 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. 7 e Updated REB after modification of priority of a periodic event.

214

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

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

This means that a user belonging to the administrative role DSO wants 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. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of P. From Fig. 8, it is seen that RT1 belongs to the REB. The precondition specified in Table 2 for command C10 is thus satisfied. Hence, command execution proceeds. After successful execution of the command, the postconditions must 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)

This means that a user belonging to the administrative role 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. From Table 5 and Fig. 3, it is seen that DSO is authorized to 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 proceeds. After successful execution of the command, the postconditions must hold: RT1 should be replaced by RT01 in the REB, where RT01 : enable MS, enabled MD / 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) This means that a user belonging to the administrative role 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. From Table 5 and Fig. 3, it is seen that DSO is authorized to 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 command C12 is thus satisfied. Hence, command execution proceeds. After successful execution of the command, the postconditions must hold: RT1 should be replaced by RT01 in the

Fig. 9 e Illustrative examples for commands that modify role triggers. Updated REB is shown after (a) Addition of an event expression, (b) Deletion of an event expression, (c) Addition of a role status expression, (d) Deletion of a role status expression, (e) Modification of priority, (f) Modification of delay.

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

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) This means that a user belonging to the administrative role 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. From Table 5 and Fig. 3, it is seen that DSO is authorized to 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, command execution proceeds. After successful execution of the command, the postconditions must hold: RT1 should be replaced by RT01 in the REB, where RT01 : enable MS, :enabled N / 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) This means that a user belonging to the administrative role 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. From Table 5 and Fig. 3, it is seen that DSO is authorized to 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 command C14 are thus satisfied. Hence, command execution proceeds. After successful execution of the command, the postconditions must hold: RT1 should be replaced by RT01 in 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)

215

This means that a user belonging to the administrative role 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. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of P. From Fig. 9(e), it is seen that RT1 belongs to the REB. The precondition specified in Table 2 for command C15 is thus satisfied. Hence, command execution proceeds. After successful execution of the command, the postconditions must hold: RT1 should be replaced by RT01 in the 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)) This means that a user belonging to the administrative role DSO wants to add a new periodic event for the regular role MO. 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). From Table 5 and Fig. 3, it is seen that DSO is authorized to add a new periodic event for regular role MO. The new periodic 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)) This means that a user belonging to the administrative role DSO wants to add a new role trigger for the regular role MS.

Fig. 10 e Illustrative examples for commands that add new members to REB. Updated REB is shown after (a) Addition of a periodic event, (b) Addition of a role trigger.

216

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

The new role trigger will be given by the following expression (enable MO, enabled MD / H: enable MS after 3). From Table 5 and Fig. 3, it is seen that DSO is authorized to 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 postconditions must hold: a new role trigger RT2 for role MS 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) This means that a user belonging to the administrative role DSO wants to delete the role trigger RT1 of the regular role P from the REB of the system. From Table 5 and Fig. 3, it is seen that DSO is authorized to modify the REB entry of P. From Fig. 10(b), it is seen that RT1 belongs to the REB. The precondition specified in Table 4 for command C18 is thus satisfied. Hence, command execution proceeds. After successful execution of the command, the 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 successful 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 standard for access control with applications in operating systems, 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 periodic 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 temporal constraints on roles, user-role assignment, permissionrole 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 contextaware 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 administrative 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 independent 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 administrative 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

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

modeling TRBAC and GTRBAC systems. However, they consider only a fixed set of pre-defined rules for state transitions. Uzun et al. (Uzun et al., 2012) propose some administrative functions for temporal RBAC to perform security analysis. Specifically, they define a schedule to represent periodic 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 administrative model. Although the proposed AMTRAC model uses existing components of ARBAC97 for managing the nontemporal aspects of TRBAC, a completely new set of eighteen 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 administration 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 various ways by which members 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 dependencies 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 administrative model 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

217

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 resources there is a need for formal analysis of security properties 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, administrative 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 administrative 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 activation constraints, duration constraints, etc. We plan to work on this in future.

references

Aich S, Sural S, Majumdar AK. STARBAC: spatiotemporal role based access control. In: OTM’07 Proc. of the 2007 OTM Confederated international conference on meaningful internet systems: CoopIS, DOA, ODBASE, GADA, and IS, Vol. Part II; 2007. p. 1567e82. Aich S, Mondal S, Sural S, Majumdar AK. Role based access control with spatiotemporal context for mobile applications. Transactions on Computational Science 2009;IV:177e99. Ammann P, Sandhu RS. Safety analysis for the extended schematic protection model. In: Proc. IEEE symposium on security and privacy 1991. p. 87e97. Bertino E, Bonatti P, Ferrari E. TRBAC: a temporal role based access control model. ACM Transactions on Information and System Security 2001:191e233. Bertino E, Catania B, Damiani ML, Perlasca P. GEO-RBAC: a spatially aware RBAC. ACM Transactions on Information and System Security 2007:29e37. Bhatti R, Ghafoor A, Bertino E, Joshi JBD. X-GTRBAC admin: a decentralized administration model for enterprise wide access control. In: SACMAT 2004, Proc. of the 9th ACM symposium on access control models and technologies 2004. p. 78e86. Bhatti R, Ghafoor A, Bertino E, Joshi JBD. X-GTRBAC: an XMLbased policy specification framework and architecture for enterprise-wide access control. ACM Transactions on Information and System Security (TISSEC) 2005:187e227. Harrison MA, Ruzzo WL, Ullman JD. On protection in operating systems. Communications of the ACM 1976:461e71.

218

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

Jha S, Li N, Tripunitara M, Wang Q, Winsborough W. Towards formal verification of role-based access control policies. IEEE Transactions on Dependable and Secure Computing 2008:242e55. Jin X, Krishnan R, Sandhu RS. A unified attribute-based access control model covering DAC, MAC and RBAC. In: DBSec’12 Proc. of the 26th Annual IFIP WG 11.3 conference on data and applications security and privacy 2012. p. 41e55. Joshi JBD, Bertino E, Latif U, Ghafoor A. A generalized temporal role-based access control model. IEEE Transactions on Knowledge and Data Engineering 2005:4e23. Li N, Tripunitara M. Security analysis in role-based access control. ACM Transactions on Information and System Security 2006:391e420. Mondal S, Sural S. Security analysis of temporal-RBAC using timed automata. In: Proc. of the 4th international conference on information assurance and security, (IAS08). Naples, Italy: IEEE Computer Society Press; 2008. p. 37e40. Mondal S, Sural S, Atluri V. Towards formal security analysis of GTRBAC using timed automata. In: Proc. of the 14th ACM symposium on access control models and technologies (SACMAT) 2009. p. 33e42. Osborn S. Mandatory access control and role-based access control revisited. In: RBAC ’97 Proc. of the 2nd ACM workshop on rolebased access control 1997. p. 31e40. Osborn S, Sandhu R, Munawer Q. Configuring role-based access control to enforce mandatory and discretionary access control policies. In: ACM transactions on information and system security (TISSEC) 2000. p. 85e106. Ray I, Kumar M, Yu L. LRBAC: a location-aware role-based access control model. In: Proc. of the 2nd international conference on information systems security 2006. p. 147e61. Sandhu RS. The schematic protection model: its definition and analysis for acyclic attenuating schemes. Journal of the ACM 1988:404e32. Sandhu RS. The typed access matrix model. In: Proc. IEEE symposium on research in security and privacy 1992. p. 122e36. Sandhu R, Munawer Q. The ARBAC99 model for administration of roles. In: ACSAC 1999, Proc. of the 15th Annual computer security applications conference 1999. p. 229e38. Sandhu R, Oh S. A model for role administration using organization structure. In: SACMAT 2002, Proc. of the 7th ACM symposium on access control models and technologies 2002. p. 155e62. Sandhu R, Coyne E, Feinstein H, Youman C. Role-based access control models. IEEE Computer 1996:38e47. Sandhu R, Bhamidipati V, Munawer Q. The ARBAC97 model for role-based administration of roles. In: ACM transactions on information and system security (TISSEC) 1999. p. 105e35. Schaad A, Moffett JD, Jacob J. The role-based access control system of a European bank: a case study and discussion. In:

SACMAT 2002, Proc. of the 6th ACM symposium on access control 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 operating systems principles 1977. p. 141e50. Tripunitara MV, Li N. The foundational work of Harrison-RuzzoUllman revisited. IEEE Transactions on Dependable and Secure 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 access control models and technologies 2012. p. 177e86. Manisha Sharma is a Masters student at the School of Information Technology, IIT Kharagpur, India. She received her Bachelor’s degree from the Guru Gobind Singh Indraprastha University, Delhi, India in Information Technology in 2010. Her research interests include access control, security analysis and database systems. Shamik Sural is a professor at the School of Information Technology, IIT Kharagpur, India. He received the Ph.D. degree from Jadavpur University in 2000. He has served on the Program Committee of many international conferences. He is a senior member of the IEEE and has served as the Chairman of the IEEE Kharagpur Section. He is a recipient of the Alexander von Humboldt Fellowship for Experienced Researchers. He has published more than one hundred and forty research papers in reputed international journals and conferences. His research interests include computer security, data mining and multimedia database systems. Jaideep Vaidya is an associate professor of Computer Information Systems at Rutgers University. He received the bachelor’s degree in Computer Engineering at the University of Mumbai and master’s and PhD degrees in Computer Science at Purdue University. His research interests are in privacy, security, data mining, and data management and he has published more than 90 papers in international conferences and journals. He is a recipient of US National Science Foundation Career Award and a Rutgers Board of Trustees Research Fellowship for Scholarly Excellence. He is a member of the IEEE Computer Society and a member of the ACM. Vijayalakshmi Atluri is a professor of computer information systems in the MSIS Department, and research director for the Center for Information Management, Integration and Connectivity at Rutgers University. She is currently a program director at US National Science Foundation. Her research interests include information security, spatial databases, multimedia and distributed systems. She has published extensively in premier journals and conferences. She was the recipient of the NSF CAREER Award, and the Rutgers University Research Award for untenured faculty for outstanding research contributions. She is a senior member of the IEEE Computer Society and a member of the ACM.