GEO-RBAC Admin and the Access Control Model

Spatial Domains for the Administration of

Location-based Access Control Policies

Maria Luisa Damiani

_{Elisa Bertino}

_{Claudio Silvestri}

April 24, 2008

∗_{University of Milan, Via Comelico 39, 20135 Milan,Italy,Tel.+39 02 50216372, damiani@dico.unimi.it} †_{Purdue University, US, bertino@cs.purdue.edu}

Abstract

In the last few years there has been an increasing interest for a novel category of access control models known as location-based or spatially-aware role-based access control (RBAC) models. Those models advance classical RBAC models in that they regulate the access to sensitive resources based on the position of mobile users. An issue that has not yet been investigated is how to administer spatially-aware access control poli-cies. In this paper we introduce GEO-RBAC Admin, the administration model for the location-based GEO-RBAC model. We discuss the concepts underlying such adminis-trative model and present a language for the specification of GEO-RBAC policies.

1 Introduction

An emerging category of RBAC-based access control models which is today of high interest to a large variety of application domains is that of location-based models. A model is location-based if the authorizations to access the protected resources depend on the positions of users in the reference space. For example, a doctor can be autho-rized to access the patients’ records only when inside the hospital. Location-based policies are typically motivated by the need of strong control over information access in a mobile context. Strong information access control may be needed for diverse pur-poses such as: a) To strongly safeguard the individual’s privacy in the case of sensitive personal information, such as health information. b) To protect strategic information resources, such as terrorism databases in critical homeland security infrastructures. c) For marketing reasons, because access to information resources, such as location-based services, can be granted on payment basis based on the mobility requirements of the user.

A number of location-based access control models have been recently proposed which extend with either spatial or spatio-temporal constraints over roles activation. Several important issues, however, are still open. Among these, a major issue is how to specify and administer location-based access control policies. Such problem is particularly dif-ficult when dealing with large organizations. Policy administration poses diverse prob-lems of practical relevance. We focus, in particular, on the following two: a) how to define a usable platform seamlessly integrating policies with spatial or spatio-temporal information. This problem is not trivial because spatial data management typically re-quires skills which are different from those needed in security administration. b) How to decentralize the administration of location-based policies. The interest towards the decentralized management of RBAC-based policies is motivated by the limits of RBAC which does not scale well in large organizations consisting of thousands of roles and users. What is new in the problem we pose is the need of taking into account the spatial

dimension when defining the decentralized administration model.

In this paper we address the above issues for a specific location-based access control model, GEO-RBAC. GEO-RBAC is a family of models which have been formally defined in a previous paper [1]. In GEO-RBAC the access control strategy is as follows: each role is assigned a spatial extent, referred to as (role extent); a role r becomes

effective in a session, that is, isenabled, when the session user, who has been assigned the role, is located in the extent ofr; a permissionpis granted to a user if and only if pis assigned to a role which is enabled in the user’s session. The model is centered

on two main concepts: spatial role androle schema. Aspatial role is a role with an associated role extent. A spatial role defines a spatially confined organizational function while the role extent is a spatial object, such as building or hospital, compliant with geo-spatial standards and located in thereference space. Arole schemadefines invariant properties of a set of homogeneous spatial roles, in particular: the role name; the spatial type describing the role extent; the spatial type describing the user’slogical position; and the function mapping the real position onto the logical position, referred to as (location mapping function).

The decentralized administration model of GEO-RBAC is calledGEO-RBAC Admin. Note that we use the terms administration decentralization and administration delega-tion as synonyms to mean thatsomeone has the authority of assigning administrative functions to somebody elseand thus of “distributing” the administration tasks. Fol-lowing common practice, we base our administration model on the concept ofdomain. Note that in the RBAC community there is no consensus on the meaning of domain and a variety of approaches have been proposed. We thus define the GEO-RBAC domain as the spatial context in which a location-based policy is specified (spatial domain). By paraphrasing Kern & al. [2], a spatial domain isan entity which collects objects accord-ing to some characteristic, such as the organizational structure andspatial proximity. In other words, a domain represents some sector of an organization which can be

asso-ciated with a location and in which objects and users are physically close to each other. Another relevant feature of GEO-RBAC Admin is that domains can be only created by domain administrators having adelegation permission. The domain administrators are those who can be authorized to create administrative objects, such as users, spa-tial roles, role schemas and the spaspa-tial elements of concern. Moreover, administrative objects can be shared across domains. Domains can be decomposed in smaller do-mains, referred to as (sub-domains), each associated with a smaller portion of space and with one or more administrators. We also introduce the notions of soundness and completeness of a spatial domain hierarchy. The model provides an administration lan-guage based on those concepts. GEO-RBAC Admin ultimately combines the concept of ownership typical of discretionary access control models with the concepts of spatial domain and spatial role to support decentralized administration in a spatial context. This paper is organized as follows. In the next section we discuss related work. Then we present the key design choices forGEO-RBAC Admin. The model is described in the subsequent section. Final remarks and open issues conclude the paper.

2 Related work

In this section we briefly overview related work on location-based access control mod-els; then we review major approaches to the decentralized administration of RBAC-based systems.

2.1 Location-based access control models

Location-based access control models have their roots in the context-aware models based on RBAC. The distinguishing feature of these models is that roles become active depending on the value of external variables. Unlike RBAC standard, roles are thus activated dynamically in response to context changes. For example the role employee assigned to a user can be automatically activated when the user enters the working

place during working hours. In general, the context can be either narrowly defined, and thus consists of a unique external variable or a limited number of external variables, such as time [3], or be general, and thus accounts for an arbitrary number of external variables [4]. To our knowledge the first model dealing with the spatial context is by Hansen et al. [5]. In such model the availability of roles and permissions may depend on users’ location. The approach is, however, limited in that the space model does not account for multi-granularity of location and current geo-spatial standards, and in addition does not address operational issues, such as the administration of those policies. One step further towards the definition of next generation movement-based access control models is by Fu et al. [6] that address the requirements of coalition environments. Such an environment assumes a distributed environment consisting of multiple cooperative and trustworthy servers which provide shared resources to mobile clients possibly partecipating in a teamwork. In such a context, authorizations can be granted also based on the previous positions of mobile devices. An example of such requirement is: “if a mobile device accesses a resource at sites1for too many times, then it is not allowed to access the resource on sites2”. A different direction of research

investigates role activation based on spatial and temporal conditions [7, 8, 9].

2.2 Decentralized administration of RBAC-based system

The administration of location-based policies has not received much attention. Related work mostly concerns the decentralized administration of RBAC-based systems. In particular we focus on the different interpretations of the concept of domain and on the mechanism for the distribution of administrative tasks.

In ARBAC97 [10] a domain is indirectly represented through the notion ofrole range, namely a pair of roles confining the portion of role hierarchy, namely the set of roles, that an administrator can administer. Role hierarchy characterizes also the administra-tive model proposed by Crampton [11]. Oh and Sandhu [12] propose an administration

model named ARBAC02. ARBAC02 retains the main features of ARBAC97, and adds the concept of organization unit, which represents a group of individuals involved in related tasks. The organization unit is indirectly modeled through the concepts of user pool and permission pool which seem to have limited generality. A different approach is proposed for UARBAC [13]. UARBAC is a family of administrative models for RBAC which consists of a basic model and one extensionU ARBACP_{. In particular}

U ARBACP _{adds constraint-based administrative domains; the basic idea is to assign} one or more attributes to each object in the RBAC system and then define administra-tive domains using constraints on these attributes. For example, the rolebusiness role

may consist of two attributes, thenameof the role and the organizationalunit. Then the expressionbusiness role(name=manager, unit=BranchHamburg)identifies

a role in the domainBranch Hamburg. The notion of domain is, however, not ex-plicit, in that it can be represented by the value of some arbitrary attribute of objects or even by a combination of values of attributes. Furthermore this approach makes strong assumptions on the nature of the RBAC model, in that domains can only be added if objects are parametrized. The administration of RBAC-based context-aware access control has been addressed by X-GTRBAC Admin [14]. A salient feature of this model is that domains are first class objects, namely have an identifier and can be related to other objects, in much the same way an Internet domain is defined by a name. A policy is then explicitly associated with a domain. Despite its simplicity, this notion of domain is fairly powerful, since it is actually independent from the concepts of the underlying RBAC and thus can be naturally added to a variety of models, including GEO-RBAC. In GEO-RBAC, however, spatial domains have a more articulated structure because they have attributes and are organized in a hierarchy.

Another major aspect concerns the delegation of administration. A major mechanism for administration delegation is provided by discretionary access control (DAC) mod-els [15, 16], in that a subject with a certain access permission is able to pass that

permission to another subject. Yet, those models lack the notion of domain. In the framework of RBAC-based models, and in particular in ARBAC97 and X-GTRBAC the delegation mechanism is very basic, since the hierarchy consists of only two levels, the Security System Officer and the application-dependent administrative roles. GEO-RBAC Admin presents a different approach which overcomes the limits of the those models. Specifically in GEO-RBAC Admin one is allowed to create a domain if he has been assigned the delegation permission and domains can be arbitrarily nested.

3 Outline of the approach

In this section we introduce the key design choices of the model, related in particular to the integration of the spatial dimension into policy management, the notion of domain and the rules of visibility across domains.

3.1 Seamless integration of the spatial dimension

The spatial dimension of GEO-RBAC raises a number of practical problems when a GEO-RBAC policy is created. A first problem is how to integrate the spatial infor-mation of interest for the representation of the spatial components of roles and role schemas (hereinafter simply components). For example if we need to define the role doctor over an extent representing a hospital, first we need to have available the spatial objects (hereinafter referred to asspatial features) which describe and localize hospi-tals inside the reference space. Hence we can specify the role schema, and finally the role instance. From the administration viewpoint, the problem is how to make the in-formation on hospitals available to the administrator. The problem is not trivial because in general spatial information may be complex to acquire and organize.

The approach we propose is based on the following ideas. First spatial features are considered administrative objects, that is, objects which can be created and accessed only by authorized administrators. Second, the authorized administrators are allowed to

importspatial data sets from external sources while the population of those spatial data sets is carried out outside GEO-RBAC Admin. The import operation thus integrates into the policy the references to the spatial features which are recorded elsewhere. The administrators who are only authorized to use, but not to create, spatial features, can then select from the set of imported features those of interest. As we will see shortly, the only administrators who are authorized to import spatial features are the system-defined administrators.

3.2 Administration of domains and administration delegation

A spatial domain specifies the reference space which confines the geometric extent of the spatial entities in the domain. Two domains are thus associated with two reference spaces which may be related by any spatial relationship such as disjointness or overlap. A domain is described by the pair:< d, s >wheredis the domain identifier, andsthe

reference space. The domain< T opD, T opF >is the system-defined domain with

the reference space equal to the whole Earth.

An important issue is who is allowed to create domains. Following common practice, a possible solution is to grant such a right exclusively to system-defined administrators. However, we believe that such a solution is limited because in principle every adminis-trator, not only those who are system-defined may wish to delegate the administration tasks. For that purpose, a key choice of the model is that domains may be arbitrarily nested; moreover administration can be recursively delegated to the administrators of nested domains, calledsub-domains.

Each sub-domain has one or more administrators. An administrator is a user who has been assigned anadministrative role, that is a role to which administrative permissions can be granted for the management of the policy. For example an admin (i.e. admin-istrative) role can be authorized to administer users while another admin role can be authorized to administer regular, i.e. non-administrative roles.

Each administrator can exercise his function only inside the respective domain refer-ence space. Importantly, an administrator can create a sub-domain only if the respective role has been assigned thedelegation permission. The delegation permission assigned to the administratorrof a sub-domain, authorizesrto further delegate administration.

It can be observed that this mechanism is similar to the mechanism of grant option in discretionary models, in that the subject who has the delegation permission is au-thorized to further propagate the administration delegation. There is, however, a major difference, in that the delegation permission only applies to domain administration. A sub-domain has thus an owner and such an owner is identified by an administrative role. The owner of the sub-domain is the only role which has the right to appoint and remove the administrators of that sub-domain while the administrative roles in the same domain are all at the same level, that is none of them has any power on the other roles. Therefore it cannot happen that there is a conflict over the management of domains. Conflicts may raise instead if the administrative roles of the sub-domain have been assigned the same rights. For example, if two roles are both authorized to administer the users of the domain policy, then the users in the system are shared resources that can be managed by both administrative roles. The model does not handle this kind of conflicts, allowing the maximum flexibility. However it is questionable whether replicating administration functions in the same domain is conceptually motivated or simply useful.

The last key choice is related to the management of the information about nested do-mains. In particular the problem is how to determine whether an administrative role

ris authorized to create an administrator in a domaind. Since this operation must be

only allowed ifris the owner ofd, and such an information is dynamic, we record the

information on the ownership relation into a centralized data structure calledAdmin Hierarchy.

3.3 Domain scoping rules

Given a set of domains, an important issue is to define the rules which govern the visibility and thus accessibility of objects across domains. For example, can a role schema defined in a domain be accessed and thussharedby another domain? Since this problem resembles the definition of scoping rules in programming languages, we refer to these criteria of visibility asdomain scoping rules. To our knowledge, this issue has not been investigated yet. We have identified three possible approaches to objects sharing across domains.

• Global objects. A first approach is to have a pool of objects, accessible from all the application domains, thusglobal, and only administered by system-defined administrator. The task of the domain administrator (i.e. the administrator of an application domain) is limited to the definition of the relationships between those objects, such as user-role assignment. The drawback of this approach is the limited autonomy of the domain administrator in the management of the domain policy.

• Local objects.Objects arelocalto each domain, that is they can be accessed and administered only inside a unique domain. This approach ensures the maximum autonomy; the drawback is that the objects which are of common concern for the organization must be replicated in each domain.

• Hybrid solution. A subset of the system objects are global while the remaining

system objects are local. The practical effect of this domain scoping rule is the following: when the user connects to the system and specifies the domain in which he or she is registered, the objects which become available are those local to the domain and those which are globally defined. Because of its flexibility, this is the solution adopted in GEO-RBAC.

A problem related with the choice of the hybrid approach is how to establish what is global and what instead is local. In principle, such a choice could exclusively depend on the application needs. Indeed, the choice can be also driven by usability concerns. This consideration results from the experiments we have carried out with the proto-type of the administration system which enables the creation of various elements of the domain policy which are then stored in a spatial DBMS. We have observed that some objects may be complex to specify for a “normal” administrator: for example the specification of alocation mapping function, which ideally can be whatever function returning a logical position out of the real position, entail programming capabilities that administrators do not necessarily have. It seems thus more convenient to let the system-defined administrator administer these objects, under the assumption that the member of such a role has the needed competences. In conclusion, domain scoping should be defined based on the desired trade-off between simplicity of use and admin-istrative autonomy. In the current model, the domain scoping rules are cabled in the model. Specifically the components of role schemas are global while the other objects are local. A more flexible management of domain scoping rules will be investigated as part of future activity.

4 Specification of the GEO-RBAC Admin model

We now introduce the administration model specifying first the administrative objects and permissions, then we discuss various aspects related to the concept of domain state. Finally the administration language is presented and the semantics of the major operations is formally described.

4.1 Objects

Following the formal approach of Li and Mao [13], we group objects in classes and thus define permissions over objects classes. We call system classesthe classes of

System object class Meaning

CR Regular roles class

CRS Regular role schemas class

CAR Administrative roles class

CARS Administrative role schemas class

CEX T Role extent types and instances

CLP S Logical position types and instances

CLM F Logical mapping functions

CU Users class

Table 1: The setSCof system classes

objects, referred to asadministrative objects, which are manipulated by administrative operations. Opposed to the system-classes, theapplication classesgroup application-dependent objects. We denote withSC={SC1, .., SCn}andAC={AC1, ...ACm} respectively the set of system and application classes.

A key design choice concerns the granularity of the system classes. This problem raises because the administrative objects consist not only of atomic but also of structured objects, such as role schemas and role instances, and therefore, ideally, one can choose different levels of granularity. The finer the granularity of classes is and the more flexible the administration is because one can specify very detailed permissions. On the other hand, a large number of classes may result into an excessive administrative burden. To balance the need of flexibility with the need of simplicity in administration, we choose to specify a separate class for each component of the role schema, i.e. role extents, logical positions and location mapping functions while we group in the same class the role extent types (logical position types) and the respective instances. The setSCof system classes is reported in Table 1. We distinguish betweenregularand

administrative roles and role schemas. A regular role is an application-dependent role, while an administrative role is the role in charge of policy administration and domain creation. Administrative roles and role schemas are homogeneously represented as GEO-RBAC (non-spatial) roles and role schemas.

Permission Meaning

[CR, admin] - to create and delete a regular role [CRS, admin] - to create and delete a regular role schema [CR, assignP rm] - to assign and revoke regular permissions to

regular roles

[CRS, assignP rm] - to assign and revoke regular permissions to regular role schemas

[CR, assignU ser] - to assign and revoke users to regular roles [CEX T, admin] - to create and delete role extent types and

instances

[CLP S, admin] - to create and delete logical position types and instances

[CLM F, admin] - to create and delete logical mapping func-tions

[CU, admin] - to create and delete users

[CAR, delegate] - to create and delete a sub-domain, an ad-min schema and an adad-min role for the sub-domain; to assign and revoke a user to the admin role and a permissions to an admin role of sub-domain

Table 2: The setP RM SS of system permissions

4.1.1 Permissions

The setAMS of access modesover system classes is defined as follows: AMS =

{admin, assignP rm, assignU ser, delegate}, where: admin allows one to create

and delete an object;assignPrmis to assign and revoke permissions to roles and role schemas;assignUser is to assign and revoke roles to users; delegateis to authorize and revoke administration delegation. On the other hand, the set of access modes over application objects, denoted asAMAis application dependent. We only assume the access modeadminfor creating and deleting an application object.

A permission takes the form[c, a]wherecis a class of objects andaan access mode.

Following the previous classification, we distinguish between the setP RM SS of sys-tem permissions and the setP RM SAof application permissions.

Let us focus on system permission. The setP RM SSof system permissions is reported in Table 2. In general, each access mode authorizes two or more operations. In partic-ular the delegate access mode authorizes the whole set of operations which are needed to delegate (or revoke) administration to the admin roles of a sub-domain.

4.2 The domain state

LetDbe the set of domain identifiers. Each domaind∈Dhas astatewhich defines

the objects and relations which can be used in such a domain. States are described at intensional level by thestate schema. The state of a domain is an instance of the state schema. We now define in more precise terms the notion of state. Preliminarily we introduce the setOdenoting the set of all possible objects; and the functionOBJ S(c)

returning the set of possible objects of classc.

The state schema is defined by a tuple consisting of the following functions:

- OBA :AC×D → 2Osuch thatOBA(c, d)⊆OBJ S(c). OBA(c, d)returns the subset of objects which are member of the application classcin domaind.

- OBS : SC ×D → 2O such thatOBS(c, d) ⊆ OBJ S(c). As above, but

OBS(c, d)returns a subset of system objects.

- PA:D→2P RM SA.PA(d)returns the set of application permissions in domain

d.

- PS:D→2P RM SS.PS(d)returns the set of system permissions in domaind. - SU A:D→2OBJ S(CU)×(OBJ S(CR)SOBJ S(CAR))._{SU A(d)}returns the set of

pairs(user, role) in domaind. The role can be regular or administrative.

- SP AI :D → 2OBJ S(CR)×P RM SA.SP AI(d)returns the set of pairs(regular role, permission)in domaind.

- SP AS :D→ 2OBJ S(CRS)×P RM SA.SP AS(d)returns the set of pairs(regular role schema, permission)in domaind.

- ASP AI :D → 2OBJ S(CRS)×(P RM SS

S

P RM SA). _{ASP A}

I(d)returns the set of pairs(admin role, permission)in domaind.

- ASP AS : D → 2OBJ S(CARS)×(P RM SS

S_{P RM S}

A). _{ASP A}

S(d)returns the set of pairs(admin role schema, permission)in domaind.

Astate, denoted asI(d)is the state schema applied to domaind. Conventionally the

admin roles in a domaindare GEO-RBAC roles having as extent the reference space

ofd.

The stateI(T opDomain)has the properties described below. - PA(T opDomain) =P RM SA

- PS(T opDomain) =P RM SS

- OBS(CAR, T opDomain) ={T opAdmin} - OBS(CU, T opDomain)⊇ {T opU ser}

- ASP AI(T opDomain) ={T opAdmin} ×(P RM SA

S

P RM SS) - SU A(T opDomain)⊇ {[T opU ser, T opAdmin]}

4.2.1 Properties of domains

Following the domain scoping rules defined in the model, the schema components in each domain are globally defined, that is those components are defined and ad-ministered in the Top Domain. This property can be formally expressed as follows:

OBS(Co, d)⊆OBS(Co, T opDomain)withCo∈ {CLP S, CLM F, CEX T}. Because the schema components can be only administered in the Top Domain, the administra-tors of an application domain are only enabled to select the components of interest from the pool of schema components available at Top Domain level and use them in “read” mode. The objects of the system classes which do not represent schema components are local to a domain and cannot be generally referred to from any other domain. Lo-cality of objects is instrumental in protecting local objects against the interference of administrators from different domains.

The information about what role has created which domain is recorded in a centralized data structure, theAdmin Hierarchy(AH). The Admin Hierarchy is updated every time a new domain or domain administrator is created or deleted. The Admin Hierarchy thus complements the domain state because specifies which admin roles have created sub-domains. Give a domaind, the pair< I(d), AH >is called thepolicy stateof

domaind.

4.2.2 Admin hierarchy

The Admin Hierarchy consists of a partially ordered set ofnodeswhere nodes take the form[d, ar] withda domain andar an admin role indor ⊥(undefined). The

admin role is undefined when the domain has been just created but the administrators of that domain have not been appointed yet. It can be easily shown that the Admin Hierarchy is a tree. In fact each node represents an admin role for a domain. Since by definition, an admin role in a domain can be only managed by a unique admin role in another domain, it follows that every node, different from the root, has a unique parent node. Therefore since the set of ancestors of a node is totally ordered and has a bottom element, the admin hierarchy is a tree. We now illustrate the meaning of Admin Hierarchy through an example.

Example 1 Assume that the member of the TopAdmin has created two domains, named

hosp1 domandhosp2 dom, representing two hospitals. The rectangles in Figure 1.a

correspond to domainshosp1 dom, and hosp2 dom with reference space hosp1 s

andhosp2 srespectively. Moreover the TopAdmin has created two admin roles, one for

each of the newly created domains, named respectivelyadmin(hosp1 s)andadmin(hosp2 s).

Notice that these two admin roles are instances of the same schemaadmin. The

mem-ber of the former role has created two sub-domains,card domander dom,

corre-sponding to the cardiology and emergency room divisions, over the spacescard sand er srespectively. The former is administered by two admin roles:sec of f icier(card s)

anduser admin(card s); the latter by a unique rolesec of f icier(er s). The

result-ing admin hierarchy is illustrated in Figure 1.b.

Figure 1: Admin hierarchy

4.3 Constraints on states

Administrative operations determine a change of state. Operations can lead, however, to an improper state. For example, if a role schema is removed from a domain while instances of that schema still exist, then the enforcement of those roles would be im-possible or fail in any case. In such case we say that the state of the domain isunsound. It may also occur that after an operation the domain is in a transitory state. For ex-ample, if in a domain there is a unique admin role which is authorized to administrate regular roles and that admin role is removed, then the regular roles which still exist cannot be administered any longer until a new administrator is appointed. In that case, we say that the state of the domain isadministratively incomplete. The notions of do-main soundness and administration completeness are important to enable the check of domains and the proper specification of administrative operations.

4.3.1 Soundness of domains

LetI∗

=<I, AH >be a policy state withAH= (T,≺). We say thatI∗is sound iff

for each domaind∈D− {T opDomain}the following conditions hold: • Roles indhave an extent contained in the reference space ofd.

• Each regular role is instance of a regular role schema ind, that is,∀d∈D,∀r∈

OBS(CR, d),∃rs∈OBS(CRS, d), rs=Sk(r).

• Each admin role is instance of an admin role schema in the parent domain, that is,∀d ∈ D,∀ar ∈ OBS(CAR, d),∃ars ∈ OBS(CARS, P arent(d)), ars =

Sk(ar).

• At least one node[d, r] ∈ T exists withr ∈ OBS(CAR, d)orr =⊥, that is every domain is represented in the Admin Hierarchy. Note that if multiple nodes

[d, r]are defined over domaindthen it means that multiple admin roles have

been created ind.

• The owner role ofdhas the delegation permission, that is:(Owner(d),[CAR, delegate])∈

d P erm(Owner(d), P arent(d)).

• The reference space ofdis spatially contained in the reference space of the parent

domain.

• Permissions assigned to an admin rolear indare included in the set of

per-missions assigned to the owner of d, that is: ∀p ∈ d P erm(ar, d) → p ∈

d P erm(Owner(d), P arent(d)).

A related problem is how to enforce domain soundness, that is how to ensure that at each instant the state of every domain is sound. The idea is to embed such an enforce-ment into the administrative operations, in such a way that every time an administrative operation is invoked, the system checks whether the state transition determined by such

an operation would lead to a sound state. If so, the operation is executed, otherwise it is forbidden. The semantics of the administrative operations will be detailed later on in the paper.

4.3.2 Administration completeness of domains

LetI∗

=<I, AH >be a sound policy state. I∗

is administratively complete iff for each domaind∈D− {T opDomain}the following conditions hold:

• There is at least one admin role.

• Each admin role is assigned at least one user, that is∀ar∈OBS(CAR, d),∃au∈

OBS(CU, d)such that(ar, au)∈SU A(d).

• If there is at least one regular role instance, regular schema or user, there must be at least one admin rolear∈OBS(CAR, d)which is authorized to administer regular roles instances, schemas and users.

• For each application objecto∈OBA(CACi, d)withACi ∈ACthere must be

an admin role which is authorized to administero.

It can be easily shown that if the above conditions are satisfied then each object in the policy state is administered by someone. In particular it cannot occur that a domain is not under the control of another domain.

An important observation is that unlike the property of domain soundness, the com-pleteness of a domain cannot be ensured by the operations which modify the policy, because such a condition may naturally arise as result of an operation. On the other hand, if domains remain incomplete they may become unmanageable. To address such an issue, we introduce a specific operation, called DomainCheck which checks the completeness of domains. The idea is to enable the domain administrator to check whether the sub-domains are complete. An issue is whether such an operation only ap-plies to the immediate descendant domains or also recursively to the nested domains.

For the sake of flexibility, we opt for the latter choice. Therefore, while the autonomy of sub-domain administrators is preserved, administrators can exercise some form of control over the decentralization of administration.

4.4 Administrative language

Admin functions

CreateRegRole(c, o) Create a regular objectoof system classc∈ {CR, CRS}

DeleteRegRole(c, o) Delete a regular objectoof system classc∈ {CR, CRS, CU}

CreateAdmRole(c, o, d) Create an admin objectoof system classc∈ {CAR, CARS}in domain d

DeleteAdmRole(c, o, d) Delete a admin objectoof system classc∈ {CAR, CARS}in domain d

CreateDomain(d, s) Create a domaindwith reference spacesas sub-domain DeleteDomain(d) Delete domaind

AddSchemaElement(c, e) Add a schema elementeof classc∈ {CEX T, CLP S, CLM F}:

GrantRegP rm(c, r, p) Assign application permissionpto regular objectrof system classc∈ {CR, CRS}

RevokeRegP rm(c, r, p) Revoke application permissionpto regular objectrof system classc∈ {CR, CRS}

GrantAdmP rm(c, r, p, d) Assign permissionpto admin objectrof system classc∈ {CAR, CARS}in domaind

RevokeAdmP rm(c, r, p, d) Revoke permissionpto admin objectrof system classc∈ {CAR, CARS}in domaind

CreateU ser(u) Add useruto the current domain

DeleteU ser(u) Delete userufrom the current domain

CreateDomainU ser(u, d) Add useruto sub-domaind DeleteDomainU ser(u, d) Delete userufrom sub-domaind GrantU serRegRole(u, r) Assign useruto regular roler RevU serRegRole(u, r) Revoke useruto regular roler

GrantU serAdminRole(u, r, d) Assign useruto admin rolerin sub-domaind RevU serAdminRole(u, r, d) Revoke userufrom admin rolerin sub-domaind

Review functions

Domains() The set of sub-domains descendant ofd

AssignedU sers(r, d) The set of users assigned to rolerin current domain

AssignedRoles(u, d) The set of roles assigned to useruin current domain

RoleP ermissions(r, d) The set of permissions granted to rolerin current domain

RoleSchemaP ermissions(r, d) The set of permissions granted to a role schemarin current domain

Display(d,{c1, ..cn}) Display on map the confine ofdalong with the contained features of typec1, .., cn

Checking functions

DomainCheck(d) Check the completeness ofdand its descendants

Table 3: Administrative operations

The administrative language consists of a set of operations for creating, managing and reviewing a GEO-RBAC policy. The application classes and access modes are assumed to be pre-defined. Table 3 reports the administrative operations. The operations are grouped in three classes: theadministrative functionssupport the creation and main-tenance of the various components of the GEO-RBAC policy; thereview functions review the results of the administrative operations, supporting as well a map-based dis-play of the spatial components of the policy; the set of checking functionsconsists of

theDomainCheckoperation to check the completeness of a domain.

In this section, we confine ourselves to describe the semantics of the operations that are instrumental in delegating administration to a sub-domain and checking domain completeness: CreateDomain, CreateAdmObj, GrantAdmPrm, GrantUserAdminRole, DomainCheck. Each of those operation is described by: a) the required permissions; b)the pre-conditions; c) the effect of the operation. The whole set of commands are formally specified in Appendix.

Conventions.Cdis the current domain in which the operation is invoked: the current domain is known because we assume it is specified by the user at login time.Cris the admin role of the initiator of the administrative operation. We assume that whenever an admin operation is invoked the system first checks whether the initiator has an admin role in the current domain. SubD(r,d) returns the set of sub-domains ofdcreated by

admin rolerwhere sub-domains are specified by their name;d P rms(r, d)returns the

set of application and system permissions assigned to admin rolerin domaind: this set

is comprehensive of the permissions assigned to both the schema ofrand directly to r;T ypeOf returns the type of a spatial feature;Contains(a, b)is a spatial predicate that is True if the extent of featurebis contained in the extent ofa. The following

functions are defined over the Admin HierarchyAH:DescendantT(r, d)returns the set of children and the descendants of[r, d]inAH;AddChildT(d, r, d0

, r0

)creates a

new node[d0

, r0

]as child of node[d, r];U pdateChildT(d, r, d0

, r0

)updates the role

field of the child of node[r, d]having domaind0with value

r0.

4.4.1 CreateDomain(d,s)

Admin function RequiredPrms Condition Effect

CreateDomain(d, s) [CAR, delegate] d /∈SubD(Cr, Cd)∧

T ypeOf(s) =Ref SpaceT ype∧ D=DS{d}

Contains(Cd.s, s) AddChildT(Cr, Cd, d,⊥)

Table 4: Operations for admin role creation

hav-ing reference spaces. The reference space must be a feature of system-defined type

RefSpaceType; further the reference space must be contained in the reference space of the current domain.Permissions and conditions: the initiator of the operation must have thedelegation permission[CAR, delegate]; further the name of the domain must not have been used for another sub-domain of the same creator. Effect: the operation adds a new domain to the set of domains, and adds a node to the Admin HierarchyT

as child of the current node.

4.4.2 CreateAdmRole(c,o,d)

Admin function RequiredPrms Condition Effect

CreateAdmRole(CARS, o,−) [CAR, delegate] o /∈ OBS(CARS, Cd) OBS(CARS, Cd) =

OBS(CARS, Cd)S{o}

CreateAdmRole(CAR, o, d) [CAR, delegate] d∈SubD(Cr, Cd)∧ OBS(CAR, d) =

o /∈ OBS(CAR, d)∧ =OBS(CAR, d)S{o}, ∃s∈OBS(CARS, Cd), s=Sk(o) U pdateChildT(Cd, Cr, d, o)

Table 5: Operations for admin role creation

Table 5 illustrates the operations which create an objectoof classc ∈ CARSSCAR in domaind. Ifo ∈ CARS the parameterdis ignored. Permissions and conditions: the initiator of the operation must have the delegation permission. We distinguish two cases: if the objectois of classCARS then the schema must not exist in the domain of the initiator. If the object is of classCARthen the corresponding admin schema must exist in the current domain, moreoverdmust be a sub-domain of the current domain

and the admin rolermust not exist ind.Effect: in the former case it is simply modified

the state of the current domain; in the latter case the operation modifies the state of the sub-domaind; further the corresponding node in the Admin Hierarchy is updated.

4.4.3 GrantAdmPrm(c,r,p,d)

Table 6 illustrates the operation which assigns a permissionpto an objectr∈CARSCARS in domaind. Ifr∈CARSthen the parameterdis ignored.Permissions and conditions: the initiator of the operation must have the delegation permission. Ifr∈C thend

Admin functions RequiredPrms Condition Effect

GrantAdmP rm(CAR, r, p, d) [CAR, delegate] p∈d P rms(Cr, Cd)∧ [r, p]∈/ASP AI(d)∧

d∈SubD(Cr, Cd) ASP AI=ASP AI(d)S{[r, p]}

GrantAdmP rm(CARS, r, p,−) [CAR, delegate] p∈d P rms(Cr, Cd)∧ [r, p]∈/ASP AS(Cd)∧

r∈OBS(CARS, Cd) ASP AS=ASP AS(Cd)S{[r, p]}

Table 6: GrantAdmPrm(c,r,p,d)

must be a sub-domain created by the initiator. Permissionpcan be either an application

or system permission. Furtherpmust be a permission of the current role.Effect: if the

permission is assigned to an admin schema, then the operation modifies the state of the current domain. Conversely, the operation modifies the state of sub-domaind, by

assigningpto the admin rolerofd.

4.4.4 GrantUserAdmRole(u,r,d)

Admin function RequiredPrms Condition Effect

GrantU serAdmRole(u, r, d) [CAR, delegate] [u, r]∈/SU A(d)∧

d∈SubD(Cr, Cd)∧

r∈OBS(CAR, d) SU A(d) =SU A(d)S{[u, r]}

Table 7: GrantUserAdmRole(u,r,d)

Table 7 describes the operation which assigns an admin user uto admin role r in

sub-domaind.Permissions and conditions: the initiator must have the delegation

per-mission; further the initiator must be the creator ofd; the admin user and role must be

present in the state of the sub-domain while user-role assignment must not.Effect: the operation modifies the state of the sub-domain, by adding the assignment user-admin role.

4.4.5 DomainCheck(d)

Checking function RequiredPrms Condition Effect

DomainCheck(d) [CAR, delegate] d∈SubD(Cd) ReturnsT rueifdis complete and each domain

d0_with[d0_{,−]∈DescendantT(−, d)is complete}

Table 8 describes the operation recursively checking the completeness of sub-domains. Permission and cconditions: the initiator must have the delegation permission; further the initiator must be the creator ofd. Effect: the operation returnsT rueif bothdand

the nested sub-domains ofdare complete.

4.5 Example

# Operation meaning

1 CreateDomain(T opCare, H1) subdomain creation 2 CreateAdmRole(CARS, AdminU ser(Ref SpaceT ype),−) creation of admin schemas 3 CreateAdmRole(CARS, AdminRole(Ref SpaceT ype),−)

4 CreateAdmRole(CAR, AdminU ser(H1), T opCare) creation of admin roles for the subdomain 5 CreateAdmRole(CAR, AdminRole(H1), T opCare)

8 GrantAdmP rm(CAR, AdminU ser(H1),[CU, admin], T opCare) assign admin permissions to admin roles 9 GrantAdmP rm(CAR, AdminU ser(H1),[CR, assignU ser], T opCare)

10 GrantAdmP rm(CAR, AdminU ser(H1),[CAR, delegate], T opCare) assign the delegate permission 11 GrantAdmP rm(CAR, AdminRole(H1),[CR, admin], T opCare)

12 GrantAdmP rm(CAR, AdminRole(H1),[CRS, admin], T opCare) 13 GrantAdmP rm(CAR, AdminRole(H1),[CR, assignP rm], T opCare) 14 GrantAdmP rm(CAR, AdminRole(H1),[CRS, assignP rm], T opCare)

15 GrantU serAdmRole(AdminU ser(H1), John, T opCare) assign admin users to admin roles 16 GrantU serAdmRole(AdminRole(H1), M ary, T opCare)

Table 9: The process of administration delegation

We now show through an example how administrative operations are applied in prac-tice. Assume that the top administrator of a large medical organization wants to del-egate the administration of the hospital calledTopCare and located in placeH1. In T opCarethere should be two admin roles. The former is for the administration of

users and user-role assignment and is calledAdminUser. AdminUser role should be also enabled to further delegate administration. The latter role, calledAdminRole, is for the administration of: role instances, role schemas and role/schema-permission as-signment. The sequence of operations leading to the delegation of administration is reported in Table 9. The top administrator first creates the domain corresponding to the hospital and then the admin roles of the newly created domain. Next he assigns the system permissions to those admin roles and finally the users.

5 Prototyping

A prototype of an access control system based on GEO-RBAC, called GEO-RBAC Workbench, has been developed. The GEO-RBAC Workbench supports the specifi-cation and testing of lospecifi-cation-based policies. Checking whether the policy meets the application requirements and in particular whether permissions have been correctly as-signed to roles is more difficult that in ordinary RBAC systems because the user is mobile, permissions depend on position and the model has a complex structure. The GEO-RBAC workbench, besides enabling the specification of the policy, allows to en-force the policy by simulating the user movement. As a result one can check whether permissions are correctly assigned to spatial roles and also collect log data from sim-ulated movement for supplementary analysis. The system is based on a simplified version of GEO-RBAC Admin, in that it supports multiple domains, but domains can be only created by the Top Administrator. The architectural framework of the GEO-RBAC is centered on the Policy Repository. The Policy Repository stores the domain location-based policies in a spatial DBMS. Administrators access the system through a Web interface upon authentication. For example, an administrator, who has logged in by specifying the proper domain, defines a role schema by selecting the spatial com-ponents from the available library of comcom-ponents (Figure 2) and then defines role in-stances (Figure 3) selecting the role schema and the role extent from a list of available feature identifiers.

The prototype is a J2EE compliant Web application deployed on Pentium 4 - 2.5GHz - server, with Sun Application server 8.1EE. The Policy Repository is implemented on Oracle Database Server 10.1. The mapping services, which are used for displaying the spatial components of the policy are developed using the programming interface of Google Maps.

Figure 2: Role schema creation

6 Open issues and conclusions

In this paper we have presented a model for the administration of a complex structured location-based access control model, GEO-RBAC. In particular the paper focuses on the problem of how defining the reference space of a location-based policy in a decen-tralized context and then delegate the administrative functions to spatial sub-domains which can be arbitrarily nested. A spatial domain is not only a container of a policy, but also confines the spatial components of such a policy. Ideally, domains can have differ-ent degree of autonomy. A first prototype has been developed that will be extended as part of the future activity. Besides the experimental activity, there is also a number of conceptual issues which are still open and which deserve significant modeling effort. The key problems we have identified are described here below.

Figure 3: Role instance creation

6.1 Sharing of administrative objects

A first problem is how to share administrative objects, and in particular users and role schemas across domains. In GEO-RBAC Admin, a useruwho is registered in domain dis not visible in a sub-domaind0. Therefore, the only way for

uto access the services

provided byd0 when located in the common reference space is to explicitly register

tod0

. The shortcoming of this solution is that users are compelled to register to all sub-domains. The question is thus how to enable a more flexible management of users, to allow the automatic registration in sub-domains.

An extension of the previous functionality is to enable the sharing of additional admin-istrative objects. This functionality seems particularly interesting for the sharing of role schemas. As schemas define common properties and permissions for a sets of roles, they allow one to specify a role ontology for the organization. Consider for example a large medical organization. It is likely that the rolesdoctorandpatienthave the same properties and permissions across the various hospitals of the organization. To enable the propagation of these properties and permissions to each hospital, a role schema can

be specified for example at the top domain and then shared with the various domains so that the local administrators can create the respective role instances in the local domain.

6.2 Supporting mobility across domains

Another problem is how to support mobility of users across access control domains. As a scenario imagine an application controlling the access to traffic information services requested by car-drivers in different cities and assume that the access control policy is decentralized, in particular a GEO-RBAC domain, and thus a local policy, is defined for each city. Assume that the user is assigned a home domain in which he can play the role of tourist within areas of Milan. The car driver however wishes to connect to additional and spatially disjoint domains, say Rome and still play roles and invoke services somehow related to those assigned to him. Suppose now that the user initially connects to the home domain. If the user is successfully authenticated a session is opened and thus a number of roles are made active in the session. The user however is mobile, thus while driving the user may run outside the extent of the home domain and enter a new domain and this in/out operation can occur several times before the car definitely stops. In doing so, the user enters the scope of different domain policies. This scenario raises several issues, including:

Roles interoperability. The user who has selected a role, sayr, may wish to play roles

somehow related torthrough out the domains he drives through so to perceive the

navigation across the reference space of domains as a continuum. It would thus be useful to introduce a more abstract notion of session, to capture the idea of navigation through a set of domains. As an example, consider this case: a driver connects to the home domain, say Milan, as tourist and then drives through various domains, say Florence and Rome. When passing through Florence and Rome the user is enabled to play roles similar to tourist in Milan. A model for inter-operating spatial roles is needed.

Lack of domain awareness. In a non-spatial multi-domain environment, the user ex-plicitly selects the domain he wants to be connected to. For example, John who has a role in university A, as researcher, may have a role in university B, as visitor, given A and B two domains of the application. Therefore, as John connects to B, he can access the services which are available under that domain to the visitor role. In our scenario we imagine a different situation: since the user is mobile and since domains have a spatial meaning, in some circumstances it may occur that the user is not aware of his position and thus of the possible domains he could connect to. The user must thus be provided by a guidance across domains.

Frequency of in/out. In the non-spatial context, the frequency with which the user connects to a domain is low and irrelevant. In the case of the mobile user, the user can leave and enter domains rapidly, depending on the speed of the user and the loca-tion of the domain. It is thus important, to free the user form the burden of connect-ing/disconnecting domains.

To our knowledge these issues have been addressed yet in the context of access control.

Acknowledgements

This work has been partially funded by the European Commission in the context of the projectGeographic Privacy-aware Knowledge Discovery and Delivery (GeoPKDD); IST-6FP-014915; web site: http://www.geopkdd.eu.

A Appendix: the operations in GEO-RBAC Admin

In this section we report the set of administrative commands along with their seman-tics. Administrative commands are presented in three distinct tables: Table 10 con-tains the administrative functions for the management of regular roles and regular role-permission assignment; Table 11 contains the administrative functions for the

manage-ment of administrative roles and administrative role-permission assignmanage-ment; Table 12 contains both the administrative commands for the management of users and user-role assignment, and the Review Functions.

A.1 Conventions and tables of administrative commands

Preliminarily we recall and extend the notation presented in section 4.4.

• Cdis the current domain in which the operation is invoked: the current domain is known because we assume it is specified by the user at login time. Cr is the admin role of the initiator of the administrative operation. We assume that whenever an admin operation is invoked the system first checks whether the initiator has an admin role in the current domain.

• SubD(r,d) returns the set of sub-domains of dcreated by admin role rwhere

sub-domains are specified by their name;

• d P rms(r, d)returns the set of application and system permissions assigned to admin rolerin domaind: this set is comprehensive of the permissions assigned

to both the schema ofrand directly tor; functionSk(r)returns the schema of

roler.

• T ypeOf returns the type of a spatial feature;Contains(a, b)is a spatial pred-icate that is True if the extent of featureb is contained in the extent of feature a.

• The following functions are defined over the Admin HierarchyAH:ChildrenT(r, d)

andDescendantT(r, d)return, respectively, the set of children and the

descen-dants of[r, d]inAH;AddChildT(d, r, d0

, r0

)creates a new node[d0

, r0

]as child

of node[d, r]; U pdateChildT(d, r, d0

, r0

)updates the role field of the child of

node[r, d]having domaind0 with value

r0;

DeleteChildrenT(d, r, d0

)deletes

Admin functions RequiredPrms Condition Effect

CreateRegRole(CRS, o) [CRS, admin] o∈ OBJS(CRS)∧

o /∈ OBS(CRS, Cd)∧ o.ext∈ OBS(CEX T, Cd)∧ o.lps∈ OBS(CLP S, Cd)∧

o.lmf∈ OBS(CLM F, Cd) OBS(CRS, Cd)←OBS(CRS, Cd)S{o}

CreateRegRole(CR, o) [CR, admin] o∈ OBJS(CR)∧

o /∈ OBS(CR, Cd)∧

∃s∈OBS(CRS, Cd), Sk(o)← OBS(CR, Cd)←OBS(CR, Cd)S{o}

AddSchemaElement(c, e) [c,admin] Cd=T opAdmin∧ OBS(Cc, Cd)←OBS(Cc, Cd)S{e}

withc∈ {CEX T, CLP S, CLM F} ea spatial feature

DeleteRegRole(CRS, o) [CRS, admin] o∈ OBS(CRS, Cd)∧

@r∈OBS(CR, Cd), Sk(r) =o OBS(CRS, Cd)←OBS(CRS, Cd)− {o} SP AS(d)←SP AS(d)− {[o, p]}

DeleteRegRole(CR, o) [CR, admin] r∈OBS(CR, Cd) OBS(CR, Cd)←OBS(CR, Cd)− {o}

SP AI(d)←SP AI(d)− {[o, p]} GrantRegP rm(CR, r, p) [CR, AssignP rm] p∈P RM SA∧r∈OBS(CR, Cd) SP AI(d)←SP AI(d)S{[r, p]} GrantRegP rm(CRS, r, p) [CRS, AssignP rm] p∈P RM SA∧r∈OBS(CRS, Cd) SP AS(d)←SP AS(d)S{[r, p]} RevRegP rm(CR, r, p) [CR, AssignP rm] [r, p]∈SP AI(Cd) SP AI(d)←SP AI(d)− {[r, p]} RevRegP rm(CRS, r, p) [CAR, AssignP rm] [r, p]∈SP AS(Cd) SP AS(d)←SP AS(d)− {[r, p]}

Table 10: Operations for regular role and regular role-permission management

Admin functions RequiredPrms Condition Effect

CreateAdmRole(CARS, o,−) [CAR, delegate] o∈OBJS(CARS)∧ o /∈ OBS(CARS, Cd) OBS(CARS, Cd)←OBS(CARS, Cd)S{o} CreateAdmRole(CAR, o, d) [CAR, delegate] o∈OBJS(CAR)∧d∈SubD(Cr, Cd)∧

o /∈ OBS(CAR, d)∧

∃s∈OBS(CARS, Cd), s=Sk(o) OBS(CAR, d)←OBS(CAR, d)S{o} U pdateChildT(Cd, Cr, d, o)

DeleteAdmRole(CARS, o,−) [CAR, delegate] o∈OBS(CARS, o)∧@d∈SubD(Cr, Cd),

r∈OBS(CAR, d)→Sk(r) =o OBS(CARS, Cd)←OBS(CARS, Cd)− {o} ASP AS(d)←ASP AS(d)− {[o, p]} DeleteAdmRole(CAR, o, d) [CAR, delegate] o∈OBS(CAR, d)∧d∈SubD(Cr, Cd)∧

ChildrenT(o, d) =∅ OBS(CAR, d)←OBS(CAR, d)− {o}

ASP AI(d)←ASP AI(d)− {[o, p]} U pdateChildT(Cd, Cr, d,⊥)

CreateDomain(d, s) [CAR, delegate] d /∈SubD(Cr, Cd)∧

T ypeOf(s) =Ref SpaceT ype∧Contains(Cd.s, s) D←DS{d}

AddChildT(Cr, Cd, d,⊥)

DeleteDomain(d) [CAR, delegate] d∈SubD(Cr, Cd)∧

ChildrenT(d,−) =∅ DeleteChildrenT(Cr, Cd, d)

GrantAdmP rm(CAR, r, p, d) [CAR, delegate] p∈d P rms(Cr, Cd)∧

[r, p]∈/ASP AI(d)∧

d∈SubD(Cr, Cd) ASP AI(Cd) =ASP AI(d)S{[r, p]}

GrantAdmP rm(CARS, r, p,−) [CAR, delegate] p∈d P rms(Cr, Cd)∧

[r, p]∈/ASP AS(Cd)∧

r∈OBS(CARS, Cd) ASP AS(Cd)←ASP AS(Cd)S{[r, p]}

RevAdmP rm(CARS, r, p,−) [CAR, delegate] ∀d∈SubD(Cr, Cd),[r, p]∈/ASP AI(d) ASP AS(Cd)←ASP AS(Cd)− {[r, p]} RevAdmP rm(CAR, r, p, d) [CAR, delegate] d∈SubD(Cr, Cd)∧[r, p]∈ASP AI(d)∧ ASP AI(d)←ASP AI(d)− {[r, p]}

∀d0_{∈SubD(r, d),[r, p]∈/ASP AI(d}0₎

Admin functions RequiredPrms Condition Effect

CreateU ser(u) [CU, admin] u∈OBJS(CU)∧u /∈OBS(CU, Cd) OBS(CU, Cd)←OBS(CU, Cd)S{u}

DeleteU ser(u) [CU, admin] u∈OBS(CU, Cd) OBS(CU, Cd)←OBS(CU, Cd)− {u},

SU A(d)←SU A(d)− {[u, r]|r∈OBS(CR, Cd)} CreateDomainU ser(u, d) [CAR, delegate] d∈SubD(Cr, Cd)∧

u /∈OBS(CU, d) OBS(CU, d)←OBS(CU, d)S{u}

DeleteDomainU ser(u, d) [CAR, delegate] d∈SubD(Cr, Cd)∧

u∈OBS(CU, d) OBS(CU, d)←OBS(CU, d)− {u},

SU A(d)←SU A(d)− {[u, r]|r∈OBS(CAR, d)} GrantU serRegRole(u, r) [CR, assignU ser] u∈OBS(CU, Cd)∧[u, r]∈/SU A(Cd)∧r∈OBS(CR, Cd) SU A(Cd)←SU A(Cd)S{[u, r]}

RevU serRegRole(u, r) [CR, assignU ser] [u, r]∈SU A(Cd) SU A(Cd)←SU A(Cd)− {[u, r]} GrantU serAdmRole(u, r, d) [CAR, delegate] [u, r]∈/SU A(d)∧

d∈SubD(Cr, Cd)∧r∈OBS(CAR, d) SU A(d)←SU A(d)S{[u, r]} RevU serAdmRole(u, r, d) [CAR, delegate] [u, r]∈SU A(d)∧

d∈SubD(Cr, Cd)∧

r∈OBS(CAR, d) SU A(d)←SU A(d)− {[u, r]}

Review functions

Domains() {d0_{∈D|[−, d}0_{]∈DescendantT(Cr, Cd))}

AssignedU ser(r, d) d=Cd∨d∈SubD(d) {u∈OBS(CU, d)|[u, r]∈SU A(d)}

AssignedRoles(u, d) d=Cd∨d∈SubD(d) {r∈OBS(CR, d)SOBS(CAR, d)|

[r, d]∈SU A(d)}

RoleP ermission(r, d) d=Cd∨d∈SubD(d) {p∈PS(d)SPA(d)|

[r, p]∈SP AI(d)SASP AI(d)}

RoleSchemaP ermission(r, d) d=Cd∨d∈SubD(d) {p∈PS(d)SPA(d)|

Display(d,{c1, ..cn}) Map-based display of the reference space ofd

along with the contained features of type{c1, ...cn} Table 12: Operations for user and user-role management and review functions

References

[1] M.L. Damiani, E. Bertino, B. Catania, and P. Perlasca. GEO-RBAC: A spatially Aware RBAC.ACM Transactions on Information and System Security (TISSEC), 10(1), 2007.

[2] A. Kern, A. Schaad, and J. Moffet. An Adminstration Concept for the Enterprise Role-based Access Control Model. InProceedings of the 8th ACM Symposium on Access Control Models and Technologies, 2003.

[3] E. Bertino, P. Andrea Bonatti, and E. Ferrari. TRBAC: a temporal role-based ac-cess control model.ACM Transaction on Information Systems Security, 4(3):191– 233, 2001.

[4] M.J. Covington, W. Long, S. Srinivasan, A.K. Dev, M. Ahamad, and G.D. Abowd. Securing context-aware applications using environment roles. In Pro-ceedings of the 6th ACM symposium on Access control models and technologies (SACMAT’01), pages 10–20, Chantilly, Virginia, USA, 2001. ACM Press. [5] F. Hansen and V. Oleshchuk. SRBAC: a spatial role-based access control model

for mobile systems. In Proceedings of the 7th Nordic Workshop on Secure IT Systems (NORDSEC’03), pages 129–141, Gjøvik, Norway, 2003.

[6] S. Fu and C.Z. Xu. A Coordinated Spatio-Temporal Access Control Model for Mobile Computing in Coalition Environments. InProceedings of the 19th IEEE International Parallel and Distributed Processing Symposium (IPDPS’05) -Workshop17, 2005.

[7] S.M. Chandran and J.B.D. Joshi. LoT RBAC: A Location and Time-based RBAC Model. In Proceedings of the 6th International Conference on Web Informa-tion Systems Engineering (WISE’05), pages 361–375, New York, USA, 2005. Springer-Verlag.

[8] M. Kumar and R. Newman. STRBAC - An approach towards spatio-temporal role-based access control. InCommunication, Network, and Information Security, pages 150–155, 2006.

[9] S. Aich, S.Sural, and A. K. Majumdar. STARBAC: Spatio temporal Role Based Access Control. InOTM Conferences (2) 2007: 1567-1582, 2007.

[10] R. Sandhu, V. Bhamidipati, and Q. Munawer. The ARBAC97 model for role-based administration of roles. ACM Transaction on Information Systems Secu-rity., 2(1):105–135, 1999.

[11] J. Crampton and G. Loizou. Administrative scope: A foundation for role-based administrative models. ACM Trans. Inf. Syst. Secur., 6(2):201–231, 2003. [12] S. Oh, R. Sandhu, and X. Zhang. An effective role administration model using

organization structure.ACM Trans. Inf. Syst. Secur., 9(2):113–137, 2006. [13] N. Li and Z. Mao. Administration in role-based access control. InASIACCS ’07:

Proceedings of the 2nd ACM symposium on Information, computer and commu-nications security, pages 127–138, New York, NY, USA, 2007. ACM Press. [14] R. Bhatti, J. B. D. Joshi, E. Bertino, and A. Ghafoor. X-GTRBAC Admin: A

Decentralized AdministrationModel for Enterprise-Wide Access Control. ACM Transactions on Information and System Security, 4, 2005.

[15] E. Bertino, S. Jajodia, and P. Samarati. A flexible authorization mechanism for relational data management systems.ACM Trans. Inf. Syst., 17(2):101–140, 1999. [16] P. P. Griffiths and B. W. Wade. An authorization mechanism for a relational