www.ietdl.

org

Published in IET Information Security

Received on 20th August 2008
doi: 10.1049/iet-ifs.2008.0074

ISSN 1751-8709

Using Alloy to analyse a spatio-temporal

access control model supporting delegation
M. Toahchoodee I. Ray
Computer Science Department, Colorado State University, Fort Collins, CO, USA
E-mail: iray@cs.colostate.edu

Abstract: Pervasive computing applications use the knowledge of the environment to provide better services and
functionality to the end user. Access control for such applications needs to use contextual information. Towards
this end, we proposed an access control model based on role-based access control that uses the environmental
contexts time and location to determine whether a user can get access to some resource. The model also
supports delegation which is important for dynamic applications where a user is unavailable and permissions
may have to be transferred temporarily to another user/role in order to complete a specific task. Such a
model typically has numerous features to support the requirements of various applications. The features may
interact in subtle ways to produce conflicts. Here, we propose an automated approach using Alloy for
detecting such conflicts. Alloy is supported by a software infrastructure that allows automated analysis of
models and has been used to verify industrial applications. The results obtained from the analysis will enable
the users of the model to make informed decisions.

1 Introduction possible that a user/role for doing a specific task is

temporarily unavailable and another user/role must be
With the increase in the growth of wireless networks and sensor granted access during this time to complete it. This
and mobile devices, we are moving towards an era of pervasive necessitates that the model be able to support delegation.
computing. The growth of this technology will spawn Moreover, different types of delegation need to be
applications such as the Aware Home [1] and CMU’s Aura supported because of the unpredictability of the application.
[2] that will make life easier for people. However, before such
applications can be widely deployed, it is important to ensure In an earlier work [3], we proposed a formal access control
that no authorised users can access the resources of the model for pervasive computing applications. Since RBAC is
application and cause security and privacy breaches. policy-neutral, simplifies access management and widely
Traditional access control models, such as Bell-LaPadula and used by commercial applications, we based our work on it.
role-based access control (RBAC), do not work well for We extended RBAC to incorporate environmental contexts,
pervasive computing applications because the applications are such as time and location. We also described the different
dynamic in nature and do not take into account environmental types of delegation that are supported by our model. Some
factors while making access decisions. Consequently, new of these are constrained by temporal and spatial conditions.
access control models are needed for such applications. We also showed how spatio-temporal information is used
for making access decisions. The various features supported
Access control for pervasive applications need to take into by the model were specified using logical constraints. These
account environmental factors, such as location and time, features often interact in subtle ways resulting in
before making access decisions. For instance, we may want inconsistencies and conflicts. Consequently, it is important
access to a computer be enabled when a user enters a room to analyse and understand these interactions before such
and it to be disabled when he leaves the room. Pervasive models can be widely deployed. Manual analysis is tedious
computing applications are dynamic in nature and the set and error-prone. Analysers based on theorem proving are
of users and resources are not known in advance. It is hard to use, require expertise and need manual intervention.

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 75

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

Model checkers are automated but are limited by the size of et al. [15] present a new access control model for active
the system they can verify. spaces which denote the computing environment integrating
physical spaces and embedded computing software and
In this paper, we advocate the use of Alloy [4], which hardware entities. Environmental aspects are adopted into
supports automated analysis, for checking access control the access control model for active spaces, and the space
models. Alloy is a modelling language capable of expressing roles are introduced into the implementation of the access
complex structural constraints and behaviour. Moreover, it control model based on RBAC. Covington et al. [1]
has been successfully used in the modelling and analysis of introduce environmental roles in a generalised RBAC model
real-world systems [5, 6]. Alloy is supported by an automated (GRBAC) to help control access to private information and
constraint solver called Alloy Analyser that searches instances resources in ubiquitous computing applications. The
of the model to check for satisfaction of system properties. environmental roles differ from the subject roles in RBAC
The model is automatically translated into a Boolean but do have similar properties including role activation, role
expression, which is analysed by SAT solvers embedded hierarchy and SoD. Environmental roles are also associated
within the Alloy Analyser. A user-specified scope on the with permissions and are activated when the environmental
model elements bounds the domain, making it possible to conditions change. In a subsequent work [16], Covington
create finite Boolean formulas that can be evaluated by the et al. describe the context-aware security architecture, which
SAT solver. When a property does not hold, a counter is an implementation of the GRBAC model. Ya-Jun et al.
example is produced that demonstrates how it has been [17] and Chakraborty et al. [18] proposed trust-based access
violated. This paper illustrates how the spatio-temporal control models that extend RBAC for applications where
RBAC model supporting delegation can be specified and users are not known in advance.
analysed using Alloy. The analysis demonstrates the features
of the model that may conflict with each other. Other extensions to RBAC include the temporal role-based
access control model (TRBAC) proposed by Bertino et al. [19]
The rest of the paper is organised as follows. Section 2 which adds the time dimension to the RBAC model. Joshi
describes the related work. Section 3 shows the relationship et al. [20] extend this work by proposing the generalised
of each component of core RBAC with time and location. temporal role-based access control model (GTRBAC)
Sections 4 – 7 propose different types of hierarchies, where they introduce the concept of time-based role
separation of duty (SoD) constraints and delegation that we hierarchy and time-based SoD. In a subsequent work [21],
can have in our model. Section 8 discusses how the model Joshi and Bertino extend GTRBAC to support delegation
can be analysed using Alloy. Section 9 concludes the paper operation in the presence of different types of temporal role-
with some pointers to future directions. Appendix gives the hierarchy. Researchers have also extended RBAC to
complete Alloy specification of our model. incorporate spatial information [22, 23]. Incorporating both
time and location in RBAC is addressed by several works
[24 – 26]. Chandran’s work combines the main features of
2 Related work GTRBAC and GEO-RBAC. Here again, role is enabled by
Location-based access control (LBAC) has been addressed in time constraints. The user can activate the role if the role is
works not pertaining to RBAC [2, 7, 8]. Atluri and Chun enabled and the user satisfies the location constraints
[9, 10] proposed the geospatial data authorisation model which associated with role activation. Samuel et al. [26] propose
is an authorisation model for the geospatial information. The GST-RBAC which incorporates topological spatial
requester can get access to geospatial information provided his constraints to the existing GTRBAC model. In [25], we
credentials and time of access matches the credential and propose spatio-temporal RBAC which is an extension of
temporal expressions defined in the authorisation policy. RBAC model supporting the temporal and spatial
Ardagna et al. [11] present the LBAC model where the access constraints. Although the goal of this work is similar to
is contingent upon the location information of the user and his those proposed by Chandran and Joshi [24] and Samuel
credentials. Yu et al. [12] proposed LTAM a location- et al. [26], the model can express some real-world
temporal authorisation model which focuses on controlling constraints that are not possible in the other ones. In a
user access to the different locations. Pu et al. [13] present the subsequent work [3], we extended the model to support the
context access control model, called CACM, which integrates delegation operation. Chen and Crampton [27] use a graph-
the context information to the UCONABC usage control based representation for defining a precise semantics for a
model. Context sensitive access control [14] proposed by spatio-temporal RBAC model.
Hulsebosch et al. focuses on using context information such as
time, location, velocity to control the accessibility of services Many works appear that analyse RBAC specifications.
while preserving the privacy of user information. Hengartner The formal analysis of the different types of time-based
et al. [2] discuss how location information pertaining to a user hybrid hierarchy [20, 21] is proposed by Joshi et al. in [28].
can be securely accessed. Some researchers have used formal specification languages,
such as Z and UML, to analyse RBAC specifications [23,
Researchers have also worked on extending RBAC to 29, 30]; however, these languages do not support
support ubiquitous computing applications. Sampemane automated analysis. Towards this end, researchers have

76 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

advocated the use of Alloy for modelling RBAC Our model requires representing time both at the instant
specifications. In [31], Zao et al. model basic features of level and at the interval level. A time instant is one discrete
RBAC, role hierarchy and static separation of duties point on the time line. The exact granularity of a time
SSoDs. Schaad et al. model user-role assignment, role- instant will be application dependent. A time interval is a
permission assignment, role hierarchy and SSoDs features set of time instants. We use the notation ti [ d to mean
of RBAC extension using Alloy in [32]. The authors do that ti is a time instant in the time interval d. A special
not model role activation hierarchy, dynamic separation of case of relation between two time intervals that we use is
duties (DSoDs) or the delegation operation. The authors referred to as containment. A time interval tvi is contained
briefly describe how to analyse conflicts in the context of in another interval tvj , denoted as tvi # tvj , if the set of
the model. Samuel et al. [26] also illustrate how GST- time instants in tvi is a subset of those in tvj . We
RBAC can be specified in Alloy. They describe how introduce a special time interval, which we refer to as
the various GST-RBAC functionalities, that is, user – role always, that includes all other time intervals.
assignment, role – permission assignment and user – role
activation, can be specified in Alloy. However, this work 3.2 Users
does not focus on how to identify interactions between
features that result in conflicts. Our recent work [33] fills We assume that each valid user, interested in doing some
this gap. We propose the methodology to verify the location-sensitive operation, carries a locating device which
specification of spatio-temporal RBAC model by using is able to track his location. The location of a user changes
Alloy Analyser tool. The work, however, does not support with time. The relation UserLocation (u, t) gives the
the delegation operation. The current work adapts this location of the user at any given time instant t. Since a user
approach to verify a more complex model –spatio-temporal can be associated with only one location at any given point
RBAC with delegation. of time, we have the following constraint:

UserLocation(u, t) ¼ li ^ UserLocation(u, t)
3 Relationship of core RBAC ¼ lj , (li # lj ) _ (lj # li )
entities with time and location We define a similar function UserLocations (u, d) that gives
We begin by discussing how time and location are related in the location of the user during the time interval d. Note that,
our model, and then discuss how the different entities of core a single location can be associated with multiple users at any
RBAC, namely, Users, Roles, Sessions, Permissions, Objects given point of time.
and Operations, are associated with location and time.
3.3 Objects
3.1 Representing location and time Objects can be physical or logical. Example of a physical
object is a computer. Files are examples of logical objects.
Locations that correspond to the physical world are referred Physical objects have devices that transmit their location
to as the physical locations. Physical location PLoci is a information with the timestamp. Logical objects are stored
non-empty set of points {pi , pj , . . . , pn } where a point pk is in physical objects. The location and timestamp of a logical
represented by three coordinates. Physical locations are object corresponds to the location and time of the
grouped into symbolic representations that are used by physical object containing the logical object. We assume
applications and referred to as logical locations. Examples that each object is associated with one location at any given
of logical locations are Fort Collins, Colorado etc. Logical instant of time. Each location can be associated with many
location is an abstract notion for one or more physical objects. The function ObjLocation (o, t) takes as input an
locations. We assume the existence of two translation object o and a time instant t and returns the location
functions, m and m0 , that convert from logical locations to associated with the object at time t. Similarly, the function
physical locations and vice-versa. In this work, we focus on ObjLocations (o, d ) takes as input an object o and time
the containment relation between locations that formalise interval d and returns the location associated with the object.
the idea whether one location is contained within another.
A physical location plocj is said to be contained in another
physical location plock , denoted as, plocj # plock , if the
3.4 Roles
following condition holds: 8pi [ plocj , pi [ plock . A We have three types of relations with roles. These are user –
logical location llocm is contained in llocn , denoted as, role assignment, user – role activation and permission – role
llocm # llocn , if and only if the physical location assignment. We begin by focusing on user – role
corresponding to llocm is contained within that of llocm , assignment. Often times, the assignment of user to roles is
that is m0 (llocm ) # m0 (llocn ). We assume the existence of a location and time dependent. For instance, a person can be
logical location called universe that contains all other assigned the role of U.S. citizen only in certain designated
locations. In the rest of the paper, the locations referred to locations and at certain times only. To obtain the role of
are logical locations. conference attendee, a person must register at the

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 77

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

conference location during specific time intervals. Thus, for a AssignRole and ActivateRole. The permission role
user to be assigned a role, he must be in designated locations assignment is discussed later.
during specific time intervals. In our model, a user must
satisfy spatial and temporal constraints before roles can be 3.5 Sessions
assigned. We capture this with the concept of role
allocation. A role is said to be allocated when it satisfies the In mobile computing or pervasive computing environments,
temporal and spatial constraints needed for role we have different types of sessions that can be initiated by the
assignment. A role can be assigned once it has been user. Some of these sessions can be location dependent,
allocated. RoleAllocLoc(r) gives the set of locations where others not. Thus, sessions are classified into different types.
the role can be allocated. RoleAllocDur(r) gives the time Each instance of a session is associated with some type of a
interval where the role can be allocated. Some role s can be session. The type of session instance s is given by the
allocated anywhere, in such cases RoleAllocLoc(s) ¼ function Type(s). The type of the session determines the
universe. Similarly, if role p can be assigned at any time, we allowable location. The allowable location for a session type
specify RoleAllocDur( p) ¼ always. st is given by the function SessionLoc(st). When a user u
wants to create a session, the location of the user for the
Some roles can be activated only if the user is in some entire duration of the session must be contained within the
specific locations. For instance, the role of audience of a location associated with the session. The predicate
theater can be activated only if the user is in the theater SessionUser(u,s,d ) indicates that a user u has initiated a
when the show is on. The role of conference attendee can session s for duration d.
be activated only if the user is in the conference site while
the conference is in session. In short, the user must satisfy SessionUser(u, s, d ) ) (UserLocation(u, d )
temporal and location constraints before a role can be # SessionLoc(Type(s)))
activated. We borrow the concept of role-enabling [19, 20]
to describe this. A role is said to be enabled if it satisfies Since sessions are associated with locations, not all roles can
the temporal and location constraints needed to activate it. be activated within some session. The predicate
A role can be activated only if it has been enabled. SessionRole(u,r,s,d,l ) states that user u initiates a session s
RoleEnableLoc(r) gives the location where role r can be and activates a role r for duration d and at location l.
activated and RoleEnableDur(r) gives the time interval
when the role can be activated. SessionRole(u, r, s, d , l ) ) UserRoleActivate(u, r, d , l )
^ l # SessionLoc(Type(s)))
The predicate UserRoleAssign(u,r,d,l ) states that the user
u is assigned to role r during the time interval d and location l.
For this predicate to hold, the location of the user when the 3.6 Permissions
role was assigned must be in one of the locations where the The goal of our model is to provide more security than their
role allocation can take place. Moreover, the time of role traditional counterparts. This happens because the time and
assignment must be in the interval when role allocation can location of a user and an object are taken into account before
take place. making the access decisions. Our model also allows us to
model real-world requirements where access decision is
UserRoleAssign(u, r, d , l ) contingent upon the time and location associated with the
) (UserLocation(u, d ) ¼ l ) user and the object. For example, a teller may access the
^ (l # RoleAllocLoc(r)) ^ (d # RoleAllocDur(r)) bank confidential file during working hours only if he is in
the bank and the file location is the bank secure room. Our
model should be capable of expressing such requirements.
The predicate UserRoleActivate(u,r,d,l ) is true if the user u
activated role r for the time interval d at location l. This
Permissions are associated with roles, objects and
predicate implies that the location of the user during the role
operations. We associate three additional entities with
activation must be a subset of the allowable locations
permission to deal with spatial and temporal constraints:
for the activated role and all time instants when the role
user location, object location and time. We define three
remains activated must belong to the duration when the role
functions to retrieve the values of these entities.
can be activated and the role can be activated only if it is
PermRoleLoc( p,r) specifies the allowable locations that a
assigned.
user playing the role r must be in for him to get permission
p. PermObjLoc( p,o) specifies the allowable locations that
UserRoleActivate(u, r, d , l )
the object o must be in so that the user has permission to
) (l # RoleEnableLoc(r)) ^ (d # RoleEnableDur(r)) operate on the object o. PermDur( p) specifies the allowable
^ UserRoleAssign(u, r, d , l ) time when the permission can be invoked.

The additional constraints imposed upon the model We define another predicate which we term
necessitates changing the preconditions of the functions PermRoleAcquire ( p,r,d,l). This predicate is true if role r

78 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

has permission p for duration d at location l. Note that, for Unrestricted activation hierarchy: A user who can activate a
this predicate to be true, the time interval d must be senior role can also activate a junior role at any time and at
contained in the duration where the permission can be any place. For example, a project manager can activate the
invoked and the role can be enabled. Similarly, the location code developer role at any time and at any place. If x and y
l must be contained in the places where the permission can be roles such that x  y, that is, senior role x has a role–
be invoked and role can be enabled. activation relation over junior role y, then a user assigned to
role x can activate role y at any time and at any place.
PermRoleAcquire(p, r, d , l )
) (l # (PermRoleLoc(p, r) > RoleEnableLoc(r))) (x f y) ^ UserRoleActivate(u, x, d , l )
^ (d # (PermDur(p) > RoleEnableDur(p))) ) UserRoleActivate(u, y, always, universe)

The predicate PermUserAcquire(u,o,p,d,l) means that user u Time restricted permission inheritance hierarchy: A senior role
can acquire the permission p on object o for duration d at inherits the junior role’s permissions but the duration when
location l. This is possible only when the permission p is the permissions are valid are those that are associated
assigned some role r which can be activated during d and at with the junior role. For example, a contact author can inherit
location l, the user location and object location match those the permissions of the author until the paper is submitted. If
specified in the permission, the duration d matches that x and y be roles such that x  t y, that is, senior role x has a
specified in the permission. time restricted permission–inheritance relation over junior
role y, then x inherits y’s permissions together with the
PermUserAcquire(u, o, p, d , l ) ) PermRoleAcquire(p, r, d , l ) temporal constraints associated with the permission.
^ UserRoleActivate(u, r, d , l )
(x t y) ^ PermRoleAcquire(p, y, d , l )
^ ðObjectLocation(o, d )
) PermRoleAcquire(p, x, d , universe)
# PermObjectLoc(p, o))
Time restricted activation hierarchy: A user who can activate a
senior role can activate a junior role only during the time
4 Impact of time and location when the junior role can be activated. For example, a
on role hierarchy program chair can activate a reviewer role only during the
The structure of an organisation in terms of lines of authority review period. If x and y be roles such that x t y, that is,
can be modelled as a hierarchy. This organisation structure is senior role x has a role–activation relation over junior role y,
reflected in RBAC in the form of a role hierarchy [34] which then a user assigned to role x can activate role y only at the
is a transitive, anti-symmetric relation among roles. Senior time when role y can be enabled.
roles can inherit the permissions of junior roles, or a senior
role can activate a junior role, or do both depending on the (x ft y) ^ UserRoleActivate(u, x, d , l ) ^ d # RoleEnableDur(y)
nature of the hierarchy. Joshi et al. [20] identify two basic ) UserRoleActivate(u, y, d , universe)
types of hierarchy. The first is the permission inheritance
hierarchy where a senior role x inherits the permission of a Location restricted permission inheritance hierarchy: A senior role
junior role y. The second is the role activation hierarchy inherits the junior role permissions but these permissions are
where a user assigned to a senior role can activate a junior restricted to the locations imposed on the junior roles. For
role. Each of these hierarchies may be constrained by example, a top secret scientist inherits the permission of top
location and temporal constraints. Consequently, we have a secret citizen only when he is in top secret locations. If x and
number of different hierarchical relationships in our model y be roles such that x  l y, that is, senior role x has a location
that are described below. restricted permission–inheritance relation over junior role y,
then x inherits y’s permissions together with the location
Unrestricted permission inheritance hierarchy: A senior role constraints associated with the permission.
inherits the junior roles permissions but not the spatial and
temporal constraints associated with it. For example, (x l y) ^ PermRoleAcquire(p, y, d , l )
account auditor role inherits the permissions from the
) PermRoleAcquire(p, x, always, l )
accountant role but he can use the permissions at any time
and at any place. If x and y be roles such that x  y, that
is, senior role x has an unrestricted permission– inheritance Location restricted activation hierarchy: A user who can activate a
relation over junior role y, then x inherits y’s permissions senior role can also activate a junior role but the activation is
but not the locations and time associated with it. limited to the place where the junior role can be activated.
For example, a Department Chair can activate a Staff role
only when he is in the Department. If x and y be roles such
(x  y) ^ PermRoleAcquire(p, y, d , l )
that x l y, that is, senior role x has a role–activation relation
) PermRoleAcquire(p, x, always, universe) over junior role y, then, a user assigned to role x can activate

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 79

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

role y only at the places when role y can be enabled. role at the same time and location. Let x and y be two
roles such that x = y and x,y [ SSODw(ROLES), that is,
(x fl y) ^ UserRoleActivate(u, x, d , l ) ^ l x and y are two distinct roles that are related by the
# RoleEnableLoc(y) SSODw relation. A user u assigned to role x during time d
and location l cannot be assigned to role y at the same time
) UserRoleActivate(u, y, always, l )
and location if x and y are related by SSODw .
Time location restricted permission inheritance hierarchy: A senior
(x, y) [ SSODw (ROLES)
role inherits the junior roles permissions together with the
spatial and temporal constraints imposed upon those of the ) UserRoleAssign(u, x, d , l )
junior role. For example, daytime doctor role inherits ^ UserRoleAssign(u, y, d , l ) ¼ False
permission of daytime nurse role only when he is in the
hospital during daytime. If x and y be roles such that x  tl y, Strong temporal form of SSoD – user role assignment: The same
that is, senior role x has a time–location restricted user cannot be assigned two conflicting roles at the same
permission–inheritance relation over junior role y, then x location at any time. The consultant for oil company A will
inherits y’s permissions together with the temporal and never be assigned the role of consultant for oil company B
location constraints associated with the permission. in the same country. Let x and y be two roles such that x
= y and (x,y) [ SSODt (ROLES), that is, x and y are
(x tl y) ^ PermRoleAcquire(p, y, d , l ) two distinct roles that are related by the SSODt relation. A
) PermRoleAcquire(p, x, d , l ) user u assigned to role x during time d and location l
cannot be assigned to role y at any time d 0 in the same
Time location restricted activation hierarchy: A user who can location if x and y are related by SSODt
activate a senior role can also activate a junior role but must
obey the temporal and spatial constraints imposed on the (x, y) [ SSODt (ROLES)
activation of the junior role. For example, user who has a ) UserRoleAssign(u, x, d , l )
role of mobile user can activate the weekend mobile user role
^ UserRoleAssign(u, y, d 0 , l ) ¼ False
only if he/she is in the US during the weekend. If x and y be
roles such that x ftl y, that is, senior role x has a role–
activation relation over junior role y, then, a user assigned to Strong spatial form of SSoD – user role assignment: The same
role x can activate role y only at the places and during the user cannot be assigned to two conflicting roles at any
time when role y can be enabled. location during the same time. For example, a person
cannot be assigned the roles of realtor and instructor at the
(x ftl y) ^ UserRoleActivate(u, x, d , l ) same time. Let x and y be two roles such that x = y and
(x,y) [ SSODl (ROLES), that is, x and y are two distinct
^ d # RoleEnableDur(y)
roles that are related by the SSODl relation. A user u
^ l # RoleEnableLoc(y) assigned to role x during time d and location l cannot be
) UserRoleActivate(u, y, d , l ) assigned to role y at the same time at any location l 0 if x
and y are related by SSODl .

5 Impact of time and location on (x, y) [ SSODl (ROLES)

SSoDs ) UserRoleAssign(u, x, d , l )
SoDs enables the protection against fraud that might be ^ UserRoleAssign(u, y, d, l 0 ) ¼ False
caused by the user [35]. SoD can be either static (SSoD) or
dynamic (DSoD). SSoD comes in two varieties. First one Strong form of SSoD – user role assignment: The same user
is with respect to user role assignment. The second one is cannot be assigned to two conflicting roles. For example,
with respect to permission role assignment. In the first the same person cannot be assigned the role of minority
case, the SSoD is specified as a relation between roles. The candidate and regular candidate in a job application. Let x
idea is that the same user cannot be assigned to conflicting and y be two roles such that x = y and (x,y) [
roles, i.e. roles related by SSoD. Due to the presence of SSODs(ROLES), that is, x and y are two distinct roles that
temporal and spatial constraints, we can have different are related by the SSODs relation. A user u assigned to role
flavours of SoDs – some that are constrained by temporal x during time d and location l cannot be assigned to role y
and spatial constraints and others that are not. In the at any time d 0 or at any location l 0 if x and y are related by
following, we describe the different SSoD constraints. SSODs .

Weak form of SSoD – user role assignment: The same user (x, y) [ SSODs (ROLES)
cannot be assigned to two conflicting roles during the same
) UserRoleAssign(u, x, d , l )
time and at the same location. For example, a user should
not be assigned the audience role and mobile phone user ^ UserRoleAssign(u, y, d 0 , l 0 ) ¼ False

80 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

We next consider the second form of SSoD that deals with example, the permission to issue check and permission to
permission role assignment. The idea is that the same role authorise check must not be assigned to the same role. Let
should not acquire conflicting permissions. The same p and q be two permissions such that p = q and ( p,q) [
manager should not make a request for funding as well as SSOD_PRAs , that is, p and q are two distinct permissions
approve it. that are related by SSOD_PRAs relation. A role x which
has permission p at time d and at location l cannot be
Weak form of SSoD – permission role assignment: The same assigned permission q at any time d 0 or at any location l 0 if
role cannot be assigned two conflicting permissions during p and q are related by SSOD_PRAs.
the same time and at the same location. For example, a
passenger role should not be assigned the permission to go (p, q) [ SSOD PRAs
aboard the plane and use the cell phone at the same place ) PermRoleAcquire(p, x, d , l )
and time. Let p and q be two permissions such that p = q
^ PermRoleAcquire(q, x, d 0 , l 0 ) ¼ False
and ( p,q) [ SSOD_PRAw , that is, p and q are two
distinct permissions that are related by the SSOD_PRAw
relation. A role x which has permission p at time d and
location l cannot be assigned permission q at the same time
6 Impact of time and location
and location if p and q are related by SSOD_PRAw . on DSoDs
SSoD ensures that a user does not get assigned conflicting
(p, q) [ SSOD PRAw roles or a role is not assigned conflicting permissions.
) PermRoleAcquire(p, x, d , l ) DSoD addresses the problem that a user is not able to
^ PermRoleAcquire(q, x, d , l ) ¼ False activate conflicting roles during the same session.

Strong temporal form of SSoD – permission role assignment: Weak form of DSoD: This allows the same user to activate two
The same role cannot be assigned two conflicting conflicting roles in the same session but not during the same
permissions at the same location at any time. In the top time and in the same location. A user can activate a sales
secret base, if any role has a permission to access the high assistant role and a customer role in the same session but not
confidential information, the permission to store or during the same time and in the same location.
distribute information should not be granted to that role.
Let p and q be two permissions such that p = q and ( p,q) Let x and y be two roles such that x = y and (x,y) [
[ SSOD_PRAt , that is, p and q are two distinct DSODw , that is, two distinct roles x and y are related by
permissions that are related by the SSOD_PRAt relation. DSODw . If roles x and y are related through weak DSoD
A role x which has permission p at time d and location l and if user u has activated role x in some session s for
cannot be assigned permission q at time d 0 in the same duration d and location l, then u cannot activate role y
location if p and q are related by SSOD_PRAt. during the same time d and in the same location l in
session s .
(p, q) [ SSOD PRAt
) PermRoleAcquire(p, x, d , l ) (x, y) [ DSODw ) SessionRole(u, x, s, d , l )
^ PermRoleAcquire(q, x, d 0 , l ) ¼ False ^ SessionRole(u, y, s, d , l ) ¼ False

Strong spatial form of SSoD – permission role assignment: The Strong temporal form of DSoD: This allows the same user to
same role cannot be assigned two conflicting permissions at activate two conflicting roles in the same session but not in
any location during the time. For example, the permission the same location at any time. For example, in a teaching
to access the exam paper and access the answer key should session in a classroom, a user cannot activate the grader
not be assigned for the same time. Let p and q be two role and the student role at any time. Let x and y be two
permissions such that p = q and ( p,q) [ SSOD_PRAl , roles such that x = y and (x,y) [ DSODt , that is, two
that is, p and q are two distinct permissions that are related distinct roles x and y are related by DSODt . If roles x and
by the SSOD_PRAl relation. A role x which has y are related through strong temporal DSoD and if user u
permission p at time d and location l cannot be assigned has activated role x in some session s, then u can never
permission q at the same time at any location l 0 if p and q activate role y at any time d 0 at the same location in the
are related by SSOD_PRAl. same session.

(p, q) [ SSOD PRAl (x, y) [ DSODt ) SessionRole(u, x, s, d , l )

) PermRoleAcquire(p, x, d , l ) ^ SessionRole(u, y, s, d 0 , l ) ¼ False
^ PermRoleAcquire(q, x, d , l 0 ) ¼ False
Strong spatial form of DSoD: This allows the same user to
Strong form of SSoD – permission role assignment: The same activate two conflicting roles in the same session but not at
role cannot be assigned two conflicting permissions. For the same time in any location. If a user has activated the

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 81

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

graduate teaching assistant role in his office, he cannot permissions in the set Perm to user v without any temporal
activate the lab operator role at the same time in any or spatial constraints. This will allow v to invoke the
location. Let x and y be two roles such that x = y and permissions at any time or at any place.
(x,y) [ DSODl , that is, two distinct roles x and y are
related by DSODl . If roles x and y are related through 8p [ Perm, DelegateU2U Pu (u, v, Perm)
strong spatial DSoD and if user u has activated role x in ^ PermUserAcquire(u, o, p, d , l )
some session s, then u can never activate role y in session s
) PermUserAcquire(v, o, p, d , l )
during the same time in any location
U2U time restricted permission delegation: The delegator places
(x, y) [ DSODl ) SessionRole(u, x, s, d , l )
time restrictions on when the delegatee can invoke the
^ SessionRole(u, y, s, d , l 0 ) ¼ False permissions. However, no special restrictions are placed
with respect to location – the delegatee can invoke the
Strong form of DSoD: A user can never activate the roles permission at any place that the delegator could do so. The
related through strong DSoD. For example, a user cannot professor can delegate his permission to proctor an exam to
be both a code developer and a code tester in the same the teaching assistant while he is on travel. Let
session. Let x and y be two roles such that x = y and DelegateU2U_Pt (u, v, Perm, d 0 ) be the predicate that
(x,y) [ DSODs . If roles x and y are related through strong allows user u to delegate the permissions in the set Perm to
DSoD and if user u has activated role x in some session s, user v for the duration d 0 .
then u can never activate role y in the same session.
8p [ Perm, DelegateU2U Pt (u, v, Perm, d 0 )
(x, y) [ DSODs ) SessionRole(u, x, s, d , l )
^ PermUserAcquire(u, o, p, d , l ) ^ (d 0 # d )
^ SessionRole(u, y, s, d 0 , l 0 ) ¼ False
) PermUserAcquire(v, o, p, d 0 , l )

7 Impact of time and location on U2U location restricted permission delegation: A delegator can
place spatial restrictions on when the delegatee can invoke
delegation the permissions. However, the only temporal restriction is
Many situations require the temporary transfer of access that the delegatee can invoke the permissions during the
rights to accomplish a given task. For example, in a period when the original permission is valid. The teaching
pervasive computing application, a doctor may give certain assistant can delegate the permission regarding lab
privilege to a trained nurse, when he is taking a short supervision to the lab operator only in the Computer Lab.
break. In such situations, the doctor can give a subset of his Let DelegateU2U_Pl (u, v, Perm, l0 ) be the predicate that
permission to the nurse for a given period of time. There allows user u to delegate the permissions in the set Perm to
are a number of different types of delegation. The entity user v in the location l 0 .
that transfers his privileges temporarily to another entity is
often referred to as the delegator. The entity who receives 8p [ Perm, DelegateU2U Pl (u, v, Perm, l 0 )
the privilege is known as the delegatee. The delegator ^ PermUserAcquire(u, o, p, d , l )
(delegatee) can be either an user or a role. Thus, we may
^ (l 0 # l ) ) PermUserAcquire(v, o, p, d , l 0 )
have four types of delegations: user to user (U2U), user to
role (U2R), role to role (R2R) and role to user (R2U).
U2U time location restricted permission delegation: In this case,
System administrators are responsible for overseeing
the delegator imposes a limit on the time and the location
delegation when the delegator is a role. Individual users
where the delegatee can invoke the permission. A nurse can
administer delegation when the delegator is an user. When
delegate his permission to oversee a patient while he is
a user is the delegator, he can delegate a subset of
resting in his room to a relative. Let DelegateU2U_Ptl (u, v,
permissions that he possesses by virtue of being assigned to
Perm, d 0 , l 0 ) be the predicate that allows user u to delegate
different roles. When a role is the delegator, he can
the permissions in the set Perm to user v in the location l 0
delegate either a set of permissions or the entire role. We
for the duration d 0 .
can therefore classify delegation on the basis of role
delegation or permission delegation. We identify the
8p [ Perm, DelegateU2U Ptl (u, v, Perm, d 0 , l 0 )
following types of delegation.
^ PermUserAcquire(u, o, p, d , l ) ^ (d 0 # d ) ^ (l 0 # l )
U2U unrestricted permission delegation: In this type of ) PermUserAcquire(v, o, p, d 0 , l 0 )
delegation, the delegatee can invoke the delegator’s
permissions at any time and at any place where the U2U unrestricted role delegation: The delegator delegates a role
delegator could invoke those permissions. The illness of the to the delegatee. The delegatee can activate the roles at any
company president caused him to delegate his email time and place where the delegator can activate those roles. A
reading privilege to his secretary. Let DelegateU2U_Pu(u, manager before relocating can delegate his roles to his
v, Perm) be the predicate that allows user u to delegate the successor in order to train him. Let DelegateU2U_Ru(u, v, r)

82 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

be the predicate that allows user u to delegate his role r to user v. 8p [ Perm, DelegateR2R Pu (r1 , r2 , Perm)^
PermRoleAcquire(p, r1 , d , l ) ^ (d # RoleEnableDur(r2 ))
DelegateU2U Ru (u, v, r) ^ UserRoleActivate(u, r, d , l )
^ (l # RoleEnableLoc(r2 ))
) UserRoleActivate(v, r, d , l )
) PermRoleAcquire(p, r2 , d , l )
U2U time restricted role delegation: In this case, the delegator
delegates a role to the delegatee but the role can be activated R2R time restricted permission delegation: The delegator role
for a more limited duration than the original role. A user can can place temporal restrictions on when the users of the
delegate his role as a teacher to a responsible student while he delegatee role can invoke the permissions. No special
is in a conference. Let DelegateU2U_Rt(u, v, r, d 0 ) be the restrictions are placed with respect to location that is the
predicate that allows user u to delegate his role r to user v for delegatee role’s users can invoke the permissions at any
the duration d 0 . place that the delegator role’s users could do so. CS599
teacher role can grant the permission to access course
DelegateU2U Rt (u, v, r, d 0 ) ^ UserRoleActivate(u, r, d , l ) materials to CS599 student role for the specific semester.
Let DelegateR2R_Pt (r1 , r2 , Perm, d 0 ) be the predicate that
^ (d 0 # RoleEnableDur(r)) ^ (d 0 # d )
allows role r1 to delegate the permissions in the set Perm
) UserRoleActivate(v, r, d 0 , l ) to role r2 for the duration d 0 .

U2U location restricted role delegation: In this case, the delegator 8p [ Perm, DelegateR2R Pt (r1 , r2 , Perm, d 0 )
delegates a role to the delegatee but the role can be activated in
^ (d 0 # d ) ^ PermRoleAcquire(p, r1 , d , l )
more limited locations than the original role. A student can
delegate his lab supervision role to another student in a ^ (l 0 # l ) ^ (d 0 # RoleEnableDur(r2 ))
designated portion of the lab only. Let DelegateU2U_Rl(u, v, ^ (l # RoleEnableLoc(r2 ))
r, l 0 ) be the predicate that allows user u to delegate his role r ) PermRoleAcquire(p, r2 , d 0 , l )
to user v in the location l 0 .
R2R location restricted permission delegation: The delegator role
Delegate Rl (u, v, r, l 0 ) ^ UserRoleActivate(u, r, d , l )
places spatial constraints on where the users of the delegatee
^ (l 0 # RoleEnableLoc(r)) ^ (l 0 # l role can invoke the permissions. No special temporal
) UserRoleActivate(v, r, d , l 0 ) constraints are placed, that is, the delegatee role’s users can
invoke the permissions at any time that the delegator role’s
U2U time location restricted role delegation: The delegator users could do so. The librarian role may grant the
delegates the role, but the delegatee can activate the role for a permission to checkout the book to the student role only at
limited duration in limited places. A student can delegate his the self-checkout station. Let DelegateR2R_Pl(r1 , r2 , Perm,
lab supervision role to another student only in the lab when l 0 ) be the predicate that allows role r1 to delegate the
he leaves the lab for emergency reasons. Let permissions in the set Perm to role r2 in the location l 0 .
DelegateU2U_Rtl (u, v, r, d 0 l 0 ) be the predicate that allows
user u to delegate his role r to user v in location l 0 and time d 0 . 8p [ Perm, DelegateR2R Pl (r1 , r2 , Perm, l 0 )
^ PermRoleAcquire(p, r1 , d , l )
DelegateU2U Rl (u, v, r, d 0 , l 0 )
^ (d # RoleEnableDur(r2 ))
^ UserRoleActivate(u, r, d , l )
^ (l 0 # RoleEnableLoc(r2 ))
^ (l 0 # RoleEnableLoc(r))
^ (l 0 # l ) ) PermRoleAcquire(p, r2 , d , l 0 )
^ (d 0 # RoleEnableDur(r))
^ (d 0 # d ) ^ (l 0 # l ) R2R time location restricted permission delegation: The
) UserRoleActivate(v, r, d 0 , l 0 ) delegator role imposes a limit on the time and the location
where the delegatee role’s users could invoke the
R2R unrestricted permission delegation: All users assigned to the permissions. The daytime doctor role may delegate the
delegatee role can invoke the delegator role’s permissions at any permission to obtain his location information to the nurse
time and at any place where the user of this delegator role could role only when he is in the hospital during the daytime. Let
invoke those permissions. The Smart Home owner role may DelegateR2R_Ptl(r1 , r2 , Perm, d 0 , l 0 ) be the predicate that
delegate the permission to check the status of security sensors allows role r1 to delegate the permissions in the set Perm to
of the home to the police officer role, so all police officers can role r2 in the location l 0 for the duration d 0 .
detect the intruder at any time at any place. Let
DelegateR2R_Pu(r1 , r2 , Perm) be the predicate that allows 8p [ Perm, DelegateR2R Ptl (r1 , r2 , Perm, d 0 , l 0 )
role r1 to delegate the permissions in the set Perm to role r2 ^ PermRoleAcquire(p, r1 , d , l ) ^ (d 0 # RoleEnableDur(r2 ))
without any temporal or spatial constraints. This will allow
^ (l 0 # RoleEnableLoc(r2 )) ^ (d 0 # d ) ^ (l 0 # l )
users in the role r2 to invoke the permissions at any time or at
any place. ) PermRoleAcquire(p, r2 , d 0 , l 0 )

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 83

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

R2R unrestricted role delegation: All users assigned to the for the duration d 0
delegatee role can activate the delegator role at any time and
at any place where the user of this delegator role DelegateR2R Rtl (r1 , r2 , d 0 , l 0 )^UserRoleActivate(u, r2 , d , l 0 )
could activate the role. In the case of company ^(d 0 # d )^(l 0 # l )
reorganisation, the manager role can be delegated to the
^(d # RoleEnableDur(r1 )
manager successor role in order to train him. Let
DelegateR2R_Ru(r1 , r2) be the predicate that allows role r1 ^(l # RoleEnableLoc(r1 ))
to be delegated to role r2. ^(d 0 # d )^(l 0 # l )
) UserRoleActivate(u, r1 , d 0 , l 0 )
DelegateR2R R u (r1 , r2 )
^ UserRoleActivate(u, r2 , d , l )
^ (d # RoleEnableDur(r1 )) 8 Model analysis
^ (l # RoleEnableLoc(r1 )) An Alloy model consists of signature declarations, fields, facts
) UserRoleActivate(u, r1 , d , l ) and predicates. Each signature consists of a set of atoms which
are the basic entities in Alloy. Atoms are indivisible (they
cannot be divided into smaller parts), immutable (their
R2R time restricted role delegation: The delegator places properties do not change) and uninterpreted (they do not
temporal constraints on when the users of the delegatee role have any inherent properties). Each field belongs to
can activate the delegator role. No special spatial constraints a signature and represents a relation between two or
are placed that is the delegatee role’s users can activate the more signatures. A relation denotes a set of tuples of atoms.
delegator role at any place that the delegator role’s users Facts are statements that define constraints on the elements
could do so. The permanent staff role can be delegated to of the model. Predicates are parameterised constraints that
the contract staff role during the contract period. Let can be invoked from within facts or other predicates.
DelegateR2R_Rt (r1 , r2 , d 0 ) be the predicate that allows role
r1 to be delegated to role r2 for the duration d 0 . The basic types in the access control model, such as, User,
Time, Location, Role, Permission and Object are represented
DelegateR2R R t (r1 , r2 , d 0 ) as signatures. For instance, the declarations shown below
^ UserRoleActivate(u, r2 , d , l ) define a set named User and a set named Role that represents
^ (d # RoleEnableDur(r1 )) the set of all users and the set of all roles in the system.
Inside the Role signature body, we have four relations,
^ (l # RoleEnableLoc(r1 )) ^ (d 0 # d )
namely, RoleAllocLoc, RoleAllocDur, RoleEnableLoc and
) UserRoleActivate(u, r1 , d 0 , l ) RoleEnableDur which relates Role to other signatures.

R2R location restricted role delegation: The delegator role can sigUser{ }
place spatial restrictions on where the users of the delegatee sigRole{
role can activate the delegator role. No special restrictions
RoleAllocLoc: Location,
are placed with respect to time that is the delegatee role’s
users can activate the delegator role at any time that the RoleAllocDur: Time,
delegator role’s users could do so. The researcher role can be RoleEnableLoc: Location,
delegated to the lab assistant role at the specific area of the RoleEnableDur: Time}
lab. Let DelegateR2R_Rl (r1 , r2 , l 0 ) be the predicate that
allows role r1 to be delegated to role r2 in the location l 0 . The different relationships between the model components are
also expressed as signatures. RoleEnable has a field called
DelegateR2R R l (r1 , r2 , l ) member that maps to a cartesian product of Role, Time and
^ UserRoleActivate(u, r2 , d , l ) Location. UserRoleAssignment, RolePermissionAssignment,
^ (d # RoleEnableDur(r1 )) UserLocation, ObjLocation, UserRoleActivate and
PermRoleAcquire are specified similarly. PermUserAcquire
^ (l # RoleEnableLoc(r1 ))
has a field called member that maps to a cartesian product
^ (l 0 # l ) ) UserRoleActivate(u, r1 , d , l 0 ) of User, Object, Permission and TimeLoc. Note that, for
PermUserAcquire, instead of declaring it as a cartesian
R2R time location restricted role delegation: In this case, the product of product of User, Object, Permission, Time and
delegator role imposes a limit on the time and the location Location, we have to define a special signature called
where the delegatee role’s users could activate the role. The TimeLoc which consists of two fields called dur and loc
full-time researcher role can be delegated to the part-time representing time and location, respectively. The rationale
researcher role only during the hiring period in the specific behind this indirect declaration is to overcome the limitation
lab. Let DelegateR2R_Rtl (r1 , r2 , d 0 , l 0 ) be the predicate of Alloy, which limits the dimension of cartesian product
that allows role r1 to be delegated to role r2 in the location l 0 to 4. And finally, RoleHierarchy has a field RHmember that

84 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

represents a relationship between Role and Role. Note that we The different types of delegation are also modelled as
use the abstract signature to represent role hierarchy, and the predicates. Consider the U2U unrestricted permission
different types of role hierarchy are modelled as the delegation. This type of delegation says that a user dtr
subsignatures of RoleHierarchy. The analyser will recognise delegates his permission p to user dte. User dte can
that role hierarchy consists of only these different types of role invoke the delegator’s permission at any time and at any place
hierarchy, and nothing else (See Fig. 1). where the delegator could invoke the permission (See Fig. 5).

The various invariants in the access control model are Finally, to check for conflicts, we create an assertion that
represented as facts in Alloy. For instance, the fact specifies the properties we want to verify and then let the
URActivate states that for user u to activate role r during the Alloy analyser validate the assertion using the check
time interval d and location l, this user has to be assigned to command. If our assertion does not hold in the specified
role r in location l during time d. Moreover, the location of scope, Alloy analyser will generate a counterexample. For
the user must be a subset of the locations where the role is example, to check the interaction of the Weak form of
enabled, and the time must be in the time interval when role SSOD permission role assignment and the R2R
r can be enabled. This is specified in Alloy as shown in unrestricted permission delegation, we make the assertion
Fig. 2. Other invariants are modelled in a similar manner.

Alloy’s fact feature is used to represents the effects of the

different hierarchies. The fact UPIHFact represents the
unrestricted permission inheritance hierarchy’s property. The Figure 4 Weak form of static separation of duty constraint
fact states that senior role sr can acquire all permission as predicate
assigned to itself together with all permissions assigned to
junior role jr. Note that the permission assigned to junior
role must never be assigned to the senior role (See Fig. 3).

The SoD constraints are modelled as predicates. Consider

the weak form of SSoDs user role assignment. This
constraint says that a user u assigned to role r1 during time
d and location l cannot be assigned to its conflicts role r2 Figure 5 U2U unrestricted permission delegation as
at the same time and location (See Fig. 4). predicate

Figure 1 Different types of role hierarchy

Figure 2 Different relationships between the model components

Figure 3 Invariant for user role activation expressed as Alloy fact

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 85

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

constraints, and permission delegation with SSoD permission

role assignments.

9 Conclusion and future work

Traditional access control models which do not take into
account environmental factors before making access decisions
may not be suitable for pervasive computing applications.
Towards this end, researchers have proposed spatio-temporal
role-based access control models. However, such models
Figure 6 Assertion to verify the interaction of role have numerous features restricted by spatio-temporal
assignment and the R2R unrestricted permission delegation constraints that may interact producing conflicts and
inconsistencies. We have shown how such a spatio-temporal
shown in Fig. 6. The assertion does not hold as illustrated by model that supports delegation can be specified and
the counterexample shown in Fig. 7. automatically analysed using Alloy. Our analysis reveals the
potential conflicts that may occur in our model.
The counterexample shows one violation instance:
A lot of work remains to be done. Our analysis reveals
Role ¼ fRole0, Role1g, Permission ¼ fPermission0,
undesirable interactions only for those case that we tested;
Permission1g, Time ¼ d, Location ¼ l PermRoleAcquire ¼
the analysis is therefore not complete. We plan to investigate
fRole1 ! Permission0 ! Time ! Location, Role1 !
new techniques that will reveal all types of undesirable
Permission1 ! Time ! Locationg. Substituting rdtr, rdte,
interactions without requiring input from the analysts. We
p, q, d, and l in r2rUPD and W_SSoD_PRA predicates with
also plan to investigate how to verify dynamic access control
Role0, Role1, Permission0, Permission1, d and l, respectively,
models where the entities and relationships are changed on
we obtain the violation. We checked the assertion on a HP-
the fly and the analysis must be done in real-time. Since
xw4400-Core2Duo-SATA with two Core2Duo 1.86 Ghz
pervasive computing applications are typically modelled as
CPU and 2 GB memory running Linux 64. We used
dynamic workflows, we need to extend our access control
Version 4.1.2 Alloy Analyser. The time taken to check this
model to support them. Moreover, it is unlikely that a single
assertion was 20 572 ms. We created assertions and tested for
access control model can fulfil all the needs for pervasive
other sources of conflicts. Our analysis revealed the various
computing applications. Towards this end, we plan to
types of conflicts. Examples include conflicts of permission
investigate how our model can be composed with other
inheritance hierarchy with SSoD constraints, activation
models, and the result verified to give assurance that the
hierarchy with DSoD constraints, role delegation with DSoD
resulting behaviour is acceptable.

10 Acknowledgment
This work was supported in part by AFOSR under contract
number FA9550-07-1-0042.

11 References
[1] COVINGTON M.J., LONG W., SRINIVASAN S., DEY A., AHAMAD M. ,
ABOWD G. : ‘Securing Context-Aware Applications Using
Environment Roles’. Proc. Sixth ACM Symp. Access
Control Models and Technologies, Chantilly, VA, USA, May
2001, pp. 10– 20

[2] HENGARTNER U. , STEENKISTE P. : ‘Implementing Access

Control to People Location Information’. Proc. Ninth ACM
Symp. Access Control Models and Technologies, Yorktown
Heights, NY, USA, June 2004, pp. 11 – 20

[3] RAY I., TOAHCHOODEE M.: ‘A spatio-temporal access control

model supporting delegation for pervasive computing
applications’. Proc. Fifth Int. Conf. Trust, Privacy & Security
Figure 7 Counterexample for assertion TestConflict14_1 in Digital Business, Turin, Italy, September 2008, pp. 48–58

86 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

[4] JACKSON D.: ‘Alloy 3.0 reference manual’, http://alloy. [16] COVINGTON M.J., FOGLA P., ZHAN Z., AHAMAD M.: ‘A context-
mit.edu/reference-manual.pdf, 2004 aware security architecture for emerging applications’.
Proc. Annual Computer Security Applications Conf., Las
[5] GEORG G., BIEMAN J., FRANCE R.B.: ‘Using Alloy and UML/ Vegas, NV, USA, December 2002, pp. 249 – 260
OCL to specify run-time configuration management:
a case study’, in EVANS A., FRANCE R., MOREIRA A., RUMPE B. (EDS.): [17] YA-JUN G., FAN H., QING-GUO Z., RONG L.: ‘An access control
‘Practical UML-based rigorous development methods – model for ubiquitous computing application’. Proc.
countering or integrating the eXtremists’ (LNI, P-7), 2001, Second Int. Conf. Mobile Technology, Applications and
pp. 128– 141 Systems, Guangzhou, China, November 2005, pp. 1 – 6

[6] TAGHDIRI M., JACKSON D.: ‘A lightweight formal analysis of a [18] CHAKRABORTY S. , RAY I.: ‘TrustBAC: integrating trust
multicast key management scheme’, in ‘Formal techniques relationships into the RBAC model for access control in
for networked and distributed systems - FORTE 2003’, open systems’. Proc. 11th ACM Symp. Access Control
(LNCS 2767), 2003, pp. 240– 256 Models and Technologies, Lake Tahoe, CA, USA, June
2006, pp. 49– 58
[7] LEONHARDT U. , MAGEE J. : ‘Security consideration for a
distributed location service’ (Imperial College of Science, [19] BERTINO E., BONATTI P.A., FERRARI E.: ‘TRBAC: a temporal
Technology and Medicine, London, UK, 1997) role-based access control model’. Proc. fifth ACM
Workshop on Role-Based Access Control, Berlin, Germany,
[8] RAY I., KUMAR M.: ‘Towards a location-based mandatory July 2000, pp. 21– 30
access control model’, Comp. Secur., 2006, 25, (1),
pp. 36– 44 [20] JOSHI J.B.D., BERTINO E., LATIF U., GHAFOOR A.: ‘A generalized
temporal role-based access control model’, IEEE Trans.
[9] ATLURI V., CHUN S.A.: ‘An authorization model for Knowl. Data Eng., 2005, 17, (1), pp. 4 – 23
geospatial data’, IEEE Trans. Dependable Secur. Compu.,
2004, 1, (4), pp. 238 – 254 [21] JOSHI J.B.D., BERTINO E. : ‘Fine-grained role-based
delegation in presence of the hybrid role hierarchy’.
[10] ATLURI V. , CHUN S.A.: ‘A geotemporal role-based Proc. 11th ACM Symp. Access Control Models and
authorisation system’, Int. J. Inf. Compu. Sec., 2007, 1, Technologies, Lake Tahoe, California, USA, June 2006,
(1/2), pp. 143– 168 pp. 81– 90

[11] ARDAGNA C.A., CREMONINI M. , DAMIANI E., DE CAPITANI DI [22] BERTINO E., CATANIA B., DAMIANI M.L., PERLASCA P.: ‘GEO-RBAC:
VIMERCATI ‘Supporting location-based S. , SAMARATI P. : a spatially aware RBAC’. Proc. 10th ACM Symp. Access
conditions in access control policies’. Proc. ACM Symp. Control Models and Technologies, Stockholm, Sweden,
Information, Computer and Communications Security, June 2005, pp. 29 – 37
Taipei, Taiwan, March 2006, pp. 212– 222
[23] RAY I., KUMAR M., YU L.: ‘LRBAC: a location-aware role-
[12] YU H., LIM E.-P.: ‘LTAM: a location-temporal authorization based access control model’. Proc. Second Int. Conf.
model’, Secure data management, (LNCS 3178) Toronto, Information Systems Security, Kolkata, India, December
Canada, August 2004, pp. 172– 186 2006, pp. 147 – 161

[13] PU F., SUN D., CAO Q., CAI H., YANG F.: ‘Pervasive computing [24] CHANDRAN S.M., JOSHI J.B.D.: ‘LoT-RBAC: a location and
context access control based on UCONABC model’. Proc. time-based RBAC model’. Proc. Sixth Int. Conf. Web
Second Int. Conf. Intelligent Information Hiding and Information Systems Engineering, New York, NY, USA,
Multimedia Signal Processing, Pasadena, CA, December November 2005, pp. 361 – 375
2006, pp. 689 – 692
[25] RAY I., TOAHCHOODEE M.: ‘A spatio-temporal role-based
[14] HULSEBOSCH R.J., SALDEN A.H., BARGH M.S., EBBEN P.W.G., REITSMA access control model’. Proc. 21st Annual IFIP WG 11.3
J.: ‘Context sensitive access control’. Proc. 10th ACM Symp. Working Conf. Data and Applications Security, Redondo
Access Control Models and Technologies, New York, NY, Beach, CA, July 2007, pp. 211– 226
USA, 2005, pp. 111 – 119
[26] SAMUEL A., GHAFOOR A. , BERTINO E.: ‘A framework for
[15] SAMPEMANE G., NALDURG P., CAMPBELL R.H.: ‘Access control specification and verification of generalized spatio-
for active spaces’. Proc. Annual Computer Security temporal role based access control model’. Technical
Applications Conf., Las Vegas, NV, USA, December 2002, Report, CERIAS TR 2007-08, Purdue University, February
pp. 343–352 2007

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 87

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

[27] CHEN L., CRAMPTON J.: ‘On spatio-temporal constraints Foundations Workshop, Rockport, MA, USA, June 1997,
and inheritance in role- based access control’. Proc. 2008 pp. 183–194
ACM Symp. Information, Computer and Communications
Security, Tokyo, Japan, March 2008, pp. 205– 216

[28] JOSHI J.B.D., BERTINO E. , GHAFOOR A., ZHANG Y.: ‘Formal 12 Appendix: Alloy specification
foundations for hybrid hierarchies in GTRBAC’, ACM of the spatio-temporal
Trans. Inf. Syst. Sec., 2008, 10, (4), pp. 1 – 39
RBAC model
[29] RAY I., LI N., FRANCE R., KIM D.-K.: ‘Using UML to visualize
role-based access control constraints’. Proc. Ninth ACM
Symp. Access Control Models and Technologies, Yorktown
Heights, NY, USA, June 2004, pp. 115 – 124

[30] YUAN C., HE Y., HE J., ZHOU Z. : ‘A verifiable formal

specification for RBAC model with constraints of separation
of duty’. Proc. Second SKLOIS Conf. Information Security
and Cryptology, Beijing, China, November 2006,
pp. 196– 210

[31] ZAO J., WEE H., CHU J., JACKSON D.: ‘RBAC schema verification
using lightweight formal model and constraint analysis’,
http://alloy.mit.edu/publications.php, 2002

[32] SCHAAD A., MOFFETT J.D. : ‘A lightweight approach to

specification and analysis of role-based access control
extensions’. Proc. Seventh ACM Symp. Access Control
Models and Technologies, Monterey, CA, USA, June 2002,
pp. 13– 22

[33] TOAHCHOODEE M., RAY I.: ‘On the formal analysis of a spatio-
temporal role-based access control model’. Proc. 22nd Annual
IFIP WG 11.3 Working Conf. on Data and Applications Security,
London, UK, July 2008, pp. 17–32

[34] SANDHU R.S., COYNE E.J., FEINSTEIN H.L., YOUMAN C.E.: ‘Role-
based access control models’, IEEE Comput., 1996, 29, (2),
pp. 38– 47

[35] SIMON R., ZURKO M.E.: ‘Separation of duty in role-

based environments’. Proc. 10th Computer Security

88 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 89

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

90 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 91

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

92 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 93

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

94 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 95

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

96 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 97

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

98 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113

& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 99

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

100 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113
& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 101

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

102 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113
& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 103

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

104 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113
& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 105

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

106 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113
& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 107

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

108 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113
& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 109

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

110 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113
& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 111

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
www.ietdl.org

112 IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75– 113
& The Institution of Engineering and Technology 2009 doi: 10.1049/iet-ifs.2008.0074

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.
 www.ietdl.org

IET Inf. Secur., 2009, Vol. 3, Iss. 3, pp. 75 – 113 113

doi: 10.1049/iet-ifs.2008.0074 & The Institution of Engineering and Technology 2009

Authorized licensd use limted to: KINGS COLEG LOND. Downlade on Novembr 30, 209 at 10:32 from IE Xplore. Restricon aply.