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,
[email protected] University, US,
[email protected] ‡ University of Milan, Italy,
[email protected]
† Purdue
1
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 policies. In this paper we introduce GEO-RBAC Admin, the administration model for the location-based GEO-RBAC model. We discuss the concepts underlying such administrative model and present a language for the specification of GEO-RBAC policies. Keywords: Access control, RBAC, spatial data, location-based services
1
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 authorized 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 purposes 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 difficult when dealing with large organizations. Policy administration poses diverse problems 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 requires 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
2
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, is enabled, when the session user, who has been assigned the role, is located in the extent of r; a permission p is granted to a user if and only if p is assigned to a role which is enabled in the user’s session. The model is centered on two main concepts: spatial role and role schema. A spatial 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 the reference space. A role schema defines 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’s logical 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 called GEO-RBAC Admin. Note that we use the terms administration decentralization and administration delegation as synonyms to mean that someone has the authority of assigning administrative functions to somebody else and thus of “distributing” the administration tasks. Following common practice, we base our administration model on the concept of domain. 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 is an entity which collects objects according to some characteristic, such as the organizational structure and spatial proximity. In other words, a domain represents some sector of an organization which can be asso-
3
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 a delegation permission. The domain administrators are those who can be authorized to create administrative objects, such as users, spatial roles, role schemas and the spatial elements of concern. Moreover, administrative objects can be shared across domains. Domains can be decomposed in smaller domains, 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 language 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 for GEO-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 models; then we review major approaches to the decentralized administration of RBACbased 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 4
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 site s1 for too many times, then it is not allowed to access the resource on site s2 ”. 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 of role 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 administrative model proposed by Crampton [11]. Oh and Sandhu [12] propose an administration
5
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 extension U ARBAC P . In particular U ARBAC P 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 administrative domains using constraints on these attributes. For example, the role business role may consist of two attributes, the name of the role and the organizational unit. Then the expression business role(name = manager, unit = BranchHamburg) identifies a role in the domain Branch Hamburg. The notion of domain is, however, not explicit, 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) models [15, 16], in that a subject with a certain access permission is able to pass that
6
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. GEORBAC 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 information 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 as spatial features) which describe and localize hospitals 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 information 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 7
import spatial 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 systemdefined 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 > where d is the domain identifier, and s the 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 administrator, 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, called sub-domains. Each sub-domain has one or more administrators. An administrator is a user who has been assigned an administrative role, that is a role to which administrative permissions can be granted for the management of the policy. For example an admin (i.e. administrative) role can be authorized to administer users while another admin role can be authorized to administer regular, i.e. non-administrative roles.
8
Each administrator can exercise his function only inside the respective domain reference space. Importantly, an administrator can create a sub-domain only if the respective role has been assigned the delegation permission. The delegation permission assigned to the administrator r of a sub-domain, authorizes r to 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 authorized 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 domains. In particular the problem is how to determine whether an administrative role r is authorized to create an administrator in a domain d. Since this operation must be only allowed if r is the owner of d, and such an information is dynamic, we record the information on the ownership relation into a centralized data structure called Admin Hierarchy.
9
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 thus shared by another domain? Since this problem resembles the definition of scoping rules in programming languages, we refer to these criteria of visibility as domain 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, thus global, 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 are local to 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.
10
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 prototype 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 a location 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 administrative 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 classes the classes of 11
System object class CR CRS CAR CARS CEXT CLP S CLM F CU
Meaning Regular roles class Regular role schemas class Administrative roles class Administrative role schemas class Role extent types and instances Logical position types and instances Logical mapping functions Users class
Table 1: The set SC of system classes objects, referred to as administrative objects, which are manipulated by administrative operations. Opposed to the system-classes, the application classes group applicationdependent objects. We denote with SC = {SC1 , .., SCn } and AC = {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 set SC of system classes is reported in Table 1. We distinguish between regular and 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.
12
Permission [CR , admin] [CRS , admin] [CR , assignP rm] [CRS , assignP rm] [CR , assignU ser] [CEXT , admin] [CLP S , admin] [CLM F , admin] [CU , admin] [CAR , delegate]
Meaning - to create and delete a regular role - to create and delete a regular role schema - to assign and revoke regular permissions to regular roles - to assign and revoke regular permissions to regular role schemas - to assign and revoke users to regular roles - to create and delete role extent types and instances - to create and delete logical position types and instances - to create and delete logical mapping functions - to create and delete users - to create and delete a sub-domain, an admin schema and an admin role for the subdomain; to assign and revoke a user to the admin role and a permissions to an admin role of sub-domain
Table 2: The set P RM SS of system permissions 4.1.1
Permissions
The set AMS of access modes over system classes is defined as follows: AMS = {admin, assignP rm, assignU ser, delegate}, where: admin allows one to create and delete an object; assignPrm is to assign and revoke permissions to roles and role schemas; assignUser is to assign and revoke roles to users; delegate is to authorize and revoke administration delegation. On the other hand, the set of access modes over application objects, denoted as AMA is application dependent. We only assume the access mode admin for creating and deleting an application object. A permission takes the form [c, a] where c is a class of objects and a an access mode. Following the previous classification, we distinguish between the set P RM SS of system permissions and the set P RM SA of application permissions. Let us focus on system permission. The set P RM SS of system permissions is reported in Table 2. In general, each access mode authorizes two or more operations. In particular 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.
13
4.2
The domain state
Let D be the set of domain identifiers. Each domain d ∈ D has a state which defines the objects and relations which can be used in such a domain. States are described at intensional level by the state 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 set O denoting the set of all possible objects; and the function OBJS(c) returning the set of possible objects of class c. The state schema is defined by a tuple consisting of the following functions: - OBA : AC × D → 2O such that OBA (c, d) ⊆ OBJS(c). OBA (c, d) returns the subset of objects which are member of the application class c in domain d. - OBS : SC × D → 2O such that OBS (c, d) ⊆ OBJS(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 domain d. - SU A : D → 2OBJS(CU )×(OBJS(CR )
S
OBJS(CAR ))
. SU A(d) returns the set of
pairs (user, role) in domain d. The role can be regular or administrative. - SP AI : D → 2OBJS(CR )×P RM SA . SP AI (d) returns the set of pairs (regular role, permission) in domain d. - SP AS : D → 2OBJS(CRS )×P RM SA . SP AS (d) returns the set of pairs (regular role schema, permission) in domain d. - ASP AI : D → 2OBJS(CRS )×(P RM SS
S
P RM SA )
of pairs (admin role, permission) in domain d.
14
. ASP AI (d) returns the set
- ASP AS : D → 2OBJS(CARS )×(P RM SS
S
P RM SA )
. ASP AS (d) returns the
set of pairs (admin role schema, permission) in domain d. A state, denoted as I(d) is the state schema applied to domain d. Conventionally the admin roles in a domain d are GEO-RBAC roles having as extent the reference space of d. The state I(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 administered in the Top Domain. This property can be formally expressed as follows: OBS (Co , d) ⊆ OBS (Co , T opDomain) with Co ∈ {CLP S , CLM F , CEXT }. Because the schema components can be only administered in the Top Domain, the administrators 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. Locality of objects is instrumental in protecting local objects against the interference of administrators from different domains. 15
The information about what role has created which domain is recorded in a centralized data structure, the Admin 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 domain d, the pair < I(d), AH > is called the policy state of domain d. 4.2.2
Admin hierarchy
The Admin Hierarchy consists of a partially ordered set of nodes where nodes take the form [d, ar] with d a domain and ar an admin role in d or ⊥ (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 dom and hosp2 dom, representing two hospitals. The rectangles in Figure 1.a correspond to domains hosp1 dom, and hosp2 dom with reference space hosp1 s and hosp2 s respectively. Moreover the TopAdmin has created two admin roles, one for each of the newly created domains, named respectively admin(hosp1 s) and admin(hosp2 s). Notice that these two admin roles are instances of the same schema admin. The member of the former role has created two sub-domains, card dom and er dom, corresponding to the cardiology and emergency room divisions, over the spaces card s and er s respectively. The former is administered by two admin roles: sec of f icier(card s)
16
and user admin(card s); the latter by a unique role sec of f icier(er s). The resulting 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 impossible or fail in any case. In such case we say that the state of the domain is unsound. It may also occur that after an operation the domain is in a transitory state. For example, 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 is administratively incomplete. The notions of domain soundness and administration completeness are important to enable the check of domains and the proper specification of administrative operations.
17
4.3.1
Soundness of domains
Let I ∗ =< I, AH > be a policy state with AH = (T, ≺). We say that I ∗ is sound iff for each domain d ∈ D − {T opDomain} the following conditions hold: • Roles in d have an extent contained in the reference space of d. • Each regular role is instance of a regular role schema in d, 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 with r ∈ OBS (CAR , d) or r = ⊥, that is every domain is represented in the Admin Hierarchy. Note that if multiple nodes [d, r] are defined over domain d then it means that multiple admin roles have been created in d. • The owner role of d has the delegation permission, that is: (Owner(d), [CAR , delegate]) ∈ d P erm(Owner(d), P arent(d)). • The reference space of d is spatially contained in the reference space of the parent domain. • Permissions assigned to an admin role ar in d are included in the set of permissions 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 enforcement 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
18
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
Let I ∗ =< I, AH > be a sound policy state. I ∗ is administratively complete iff for each domain d ∈ 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 role ar ∈ OBS (CAR , d) which is authorized to administer regular roles instances, schemas and users. • For each application object o ∈ OBA (CACi , d) with ACi ∈ AC there must be an admin role which is authorized to administer o. 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 completeness 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 applies to the immediate descendant domains or also recursively to the nested domains. 19
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) DeleteRegRole(c, o) CreateAdmRole(c, o, d) DeleteAdmRole(c, o, d) CreateDomain(d, s) DeleteDomain(d) AddSchemaElement(c, e) GrantRegP rm(c, r, p) RevokeRegP rm(c, r, p) GrantAdmP rm(c, r, p, d) RevokeAdmP rm(c, r, p, d) CreateU ser(u) DeleteU ser(u) CreateDomainU ser(u, d) DeleteDomainU ser(u, d) GrantU serRegRole(u, r) RevU serRegRole(u, r) GrantU serAdminRole(u, r, d) RevU serAdminRole(u, r, d) Review functions Domains() AssignedU sers(r, d) AssignedRoles(u, d) RoleP ermissions(r, d) RoleSchemaP ermissions(r, d) Display(d, {c1 , ..cn }) Checking functions DomainCheck(d)
Create a regular object o of system class c ∈ {C R , CRS } Delete a regular object o of system class c ∈ {C R , CRS , CU } Create an admin object o of system class c ∈ {C AR , CARS } in domain d Delete a admin object o of system class c ∈ {C AR , CARS } in domain d Create a domain d with reference space s as sub-domain Delete domain d Add a schema element e of class c ∈ {CEXT , CLP S , CLM F }: Assign application permission p to regular object r of system class c ∈ {C R , CRS } Revoke application permission p to regular object r of system class c ∈ {C R , CRS } Assign permission p to admin object r of system class c ∈ {C AR , CARS } in domain d Revoke permission p to admin object r of system class c ∈ {C AR , CARS } in domain d Add user u to the current domain Delete user u from the current domain Add user u to sub-domain d Delete user u from sub-domain d Assign user u to regular role r Revoke user u to regular role r Assign user u to admin role r in sub-domain d Revoke user u from admin role r in sub-domain d The set of sub-domains descendant of d The set of users assigned to role r in current domain The set of roles assigned to user u in current domain The set of permissions granted to role r in current domain The set of permissions granted to a role schema r in current domain Display on map the confine of d along with the contained features of type c 1 , .., cn Check the completeness of d and 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: the administrative functions support the creation and maintenance of the various components of the GEO-RBAC policy; the review functions review the results of the administrative operations, supporting as well a map-based display of the spatial components of the policy; the set of checking functions consists of 20
the DomainCheck operation 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. Cd is 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. C r 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 d created by admin role r where sub-domains are specified by their name; d P rms(r, d) returns the set of application and system permissions assigned to admin role r in domain d: this set is comprehensive of the permissions assigned to both the schema of r and 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 feature b is contained in the extent of a. The following functions are defined over the Admin Hierarchy AH: DescendantT (r, d) returns the set of children and the descendants of [r, d] in AH; 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 domain d0 with value r 0 . 4.4.1
CreateDomain(d,s)
Admin function CreateDomain(d, s)
RequiredPrms [CAR , delegate]
Condition d∈ / SubD(Cr, Cd)∧ T ypeOf (s) = Ref SpaceT ype∧ Contains(Cd.s, s)
Effect S D = D {d} AddChildT (Cr, Cd, d, ⊥)
Table 4: Operations for admin role creation Table 4 illustrates the CreateDomain operation which creates a domain named d hav21
ing reference space s. 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 the delegation 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 Hierarchy T as child of the current node. 4.4.2
CreateAdmRole(c,o,d)
Admin function CreateAdmRole(CARS , o, −)
RequiredPrms [CAR , delegate]
Condition o∈ / OBS (CARS , Cd)
CreateAdmRole(CAR , o, d)
[CAR , delegate]
d ∈ SubD(Cr, Cd)∧ o∈ / OBS (CAR , d)∧ ∃s ∈ OBS (CARS , Cd), s = Sk(o)
Effect OBS (CARS , Cd) S = OBS (CARS , Cd) {o} OBS (CAR , d) = S = OBS (CAR , d) {o}, U pdateChildT (Cd, Cr, d, o)
Table 5: Operations for admin role creation Table 5 illustrates the operations which create an object o of class c ∈ CARS
S
CAR
in domain d. If o ∈ CARS the parameter d is ignored. Permissions and conditions: the initiator of the operation must have the delegation permission. We distinguish two cases: if the object o is of class CARS then the schema must not exist in the domain of the initiator. If the object is of class CAR then the corresponding admin schema must exist in the current domain, moreover d must be a sub-domain of the current domain and the admin role r must not exist in d. 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-domain d; 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 permission p to an object r ∈ C AR
S
CARS
in domain d. If r ∈ CARS then the parameter d is ignored. Permissions and conditions: the initiator of the operation must have the delegation permission. If r ∈ CAR then d 22
Admin functions GrantAdmP rm(CAR , r, p, d)
RequiredPrms [CAR , delegate]
GrantAdmP rm(CARS , r, p, −)
Condition p ∈ d P rms(Cr, Cd)∧ [r, p] ∈ / ASP AI (d)∧ d ∈ SubD(Cr, Cd) p ∈ d P rms(Cr, Cd)∧ [r, p] ∈ / ASP AS (Cd)∧ r ∈ OBS (CARS , Cd)
[CAR , delegate]
Effect
ASP AI = ASP AI (d)
S
ASP AS = ASP AS (Cd)
Table 6: GrantAdmPrm(c,r,p,d) must be a sub-domain created by the initiator. Permission p can be either an application or system permission. Further p must 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-domain d, by assigning p to the admin role r of d. 4.4.4
GrantUserAdmRole(u,r,d)
Admin function GrantU serAdmRole(u, r, d)
RequiredPrms [CAR , delegate]
Condition [u, r] ∈ / SU A(d)∧ d ∈ SubD(Cr, Cd)∧ r ∈ OBS (CAR , d)
Effect
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 u to admin role r in sub-domain d. Permissions and conditions: the initiator must have the delegation permission; further the initiator must be the creator of d; 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 DomainCheck(d)
RequiredPrms [CAR , delegate]
Condition d ∈ SubD(Cd)
Effect Returns T rue if d is complete and each domain d0 with [d0 , −] ∈ DescendantT (−, d) is complete
Table 8: DomainCheck(d)
23
{[r, p]} S
{[r, p]}
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 of d. Effect: the operation returns T rue if both d and the nested sub-domains of d are complete.
4.5 # 1 2 3 4 5 8 9 10 11 12 13 14 15 16
Example Operation CreateDomain(T opCare, H1 ) CreateAdmRole(CARS , AdminU ser(Ref SpaceT ype), −) CreateAdmRole(CARS , AdminRole(Ref SpaceT ype), −) CreateAdmRole(CAR , AdminU ser(H1 ), T opCare) CreateAdmRole(CAR , AdminRole(H1 ), T opCare) GrantAdmP rm(CAR , AdminU ser(H1 ), [CU , admin], T opCare) GrantAdmP rm(CAR , AdminU ser(H1 ), [CR , assignU ser], T opCare) GrantAdmP rm(CAR , AdminU ser(H1 ), [CAR , delegate], T opCare) GrantAdmP rm(CAR , AdminRole(H1 ), [CR , admin], T opCare) GrantAdmP rm(CAR , AdminRole(H1 ), [CRS , admin], T opCare) GrantAdmP rm(CAR , AdminRole(H1 ), [CR , assignP rm], T opCare) GrantAdmP rm(CAR , AdminRole(H1 ), [CRS , assignP rm], T opCare) GrantU serAdmRole(AdminU ser(H1 ), John, T opCare) GrantU serAdmRole(AdminRole(H1 ), M ary, T opCare)
meaning subdomain creation creation of admin schemas creation of admin roles for the subdomain assign admin permissions to admin roles assign the delegate permission
assign admin users to admin roles
Table 9: The process of administration delegation We now show through an example how administrative operations are applied in practice. Assume that the top administrator of a large medical organization wants to delegate the administration of the hospital called TopCare and located in place H 1 . In T opCare there should be two admin roles. The former is for the administration of users and user-role assignment and is called AdminUser. AdminUser role should be also enabled to further delegate administration. The latter role, called AdminRole, is for the administration of: role instances, role schemas and role/schema-permission assignment. 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.
24
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 specification and testing of location-based policies. Checking whether the policy meets the application requirements and in particular whether permissions have been correctly assigned 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 enforce 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 simulated 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 GEORBAC 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 components from the available library of components (Figure 2) and then defines role instances (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.
25
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 decentralized 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 different 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.
26
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 user u who is registered in domain d is not visible in a sub-domain d0 . Therefore, the only way for u to access the services provided by d0 when located in the common reference space is to explicitly register to d0 . 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 administrative 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 roles doctor and patient have 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
27
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, say r, may wish to play roles somehow related to r through 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.
28
Lack of domain awareness. In a non-spatial multi-domain environment, the user explicitly 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 location of the domain. It is thus important, to free the user form the burden of connecting/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 project Geographic 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 semantics. Administrative commands are presented in three distinct tables: Table 10 contains the administrative functions for the management of regular roles and regular rolepermission assignment; Table 11 contains the administrative functions for the manage-
29
ment of administrative roles and administrative role-permission assignment; 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. • Cd is 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 d created by admin role r where sub-domains are specified by their name; • d P rms(r, d) returns the set of application and system permissions assigned to admin role r in domain d: this set is comprehensive of the permissions assigned to both the schema of r and directly to r; function Sk(r) returns the schema of role r. • T ypeOf returns the type of a spatial feature; Contains(a, b) is a spatial predicate that is True if the extent of feature b is contained in the extent of feature a. • The following functions are defined over the Admin Hierarchy AH: ChildrenT (r, d) and DescendantT (r, d) return, respectively, the set of children and the descendants of [r, d] in AH; 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 domain d0 with value r 0 ; DeleteChildrenT (d, r, d0 ) deletes the nodes [d’-], which are children of [d, r] in AH. 30
Admin functions CreateRegRole(CRS , o)
CreateRegRole(CR , o)
AddSchemaElement(c, e) DeleteRegRole(CRS , o)
RequiredPrms [CRS , admin]
[CR , admin] [c,admin] with c ∈ {CEXT , CLP S , CLM F } [CRS , admin]
Condition o ∈ OBJS(CRS )∧ o∈ / OBS (CRS , Cd)∧ o.ext ∈ OBS (CEXT , Cd) ∧ o.lps ∈ OBS (CLP S , Cd) ∧ o.lmf ∈ OBS (CLM F , Cd) o ∈ OBJS(CR )∧ o∈ / OBS (CR , Cd)∧ ∃ s ∈ OBS (CRS , Cd), Sk(o) ← Cd = T opAdmin∧ e a spatial feature o ∈ OBS (CRS , Cd)∧ @r ∈ OBS (CR , Cd), Sk(r) = o
31
DeleteRegRole(CR , o)
[CR , admin]
r ∈ OBS (CR , Cd)
GrantRegP rm(CR , r, p) GrantRegP rm(CRS , r, p) RevRegP rm(CR , r, p) RevRegP rm(CRS , r, p)
[CR , AssignP rm] [CRS , AssignP rm] [CR , AssignP rm] [CAR , AssignP rm]
p ∈ P RM SA ∧ r ∈ OBS (CR , Cd) p ∈ P RM SA ∧ r ∈ OBS (CRS , Cd) [r, p] ∈ SP AI (Cd) [r, p] ∈ SP AS (Cd)
Effect
OBS (CRS , Cd) ← OBS (CRS , Cd)
S
{o}
S OBS (CR , Cd) ← OBS (CR , Cd)S {o} OBS (Cc , Cd) ← OBS (Cc , Cd) {e}
OBS (CRS , Cd) ← OBS (CRS , Cd) − {o} SP AS (d) ← SP AS (d) − {[o, p]} OBS (CR , Cd) ← OBS (CR , Cd) − {o} SP AI (d) ← SP AI (d) S − {[o, p]} SP AI (d) ← SP AI (d) S{[r, p]} SP AS (d) ← SP AS (d) {[r, p]} SP AI (d) ← SP AI (d) − {[r, p]} SP AS (d) ← SP AS (d) − {[r, p]}
Table 10: Operations for regular role and regular role-permission management
Admin functions CreateAdmRole(CARS , o, −) CreateAdmRole(CAR , o, d)
DeleteAdmRole(CARS , o, −)
DeleteAdmRole(CAR , o, d)
RequiredPrms [CAR , delegate] [CAR , delegate]
[CAR , delegate]
[CAR , delegate]
Condition o ∈ OBJS(CARS ) ∧ o ∈ / OBS (CARS , Cd) o ∈ OBJS(CAR ) ∧ d ∈ SubD(Cr, Cd)∧ o∈ / OBS (CAR , d)∧ ∃s ∈ OBS (CARS , Cd), s = Sk(o) o ∈ OBS (CARS , o) ∧ @d ∈ SubD(Cr, Cd), r ∈ OBS (CAR , d) → Sk(r) = o o ∈ OBS (CAR , d) ∧ d ∈ SubD(Cr, Cd)∧ ChildrenT (o, d) = ∅
[CAR , delegate]
d∈ / SubD(Cr, Cd)∧ T ypeOf (s) = Ref SpaceT ype ∧ Contains(Cd.s, s)
DeleteDomain(d)
[CAR , delegate]
GrantAdmP rm(CAR , r, p, d)
[CAR , delegate]
d ∈ SubD(Cr, Cd)∧ ChildrenT (d, −) = ∅ p ∈ d P rms(Cr, Cd)∧ [r, p] ∈ / ASP AI (d)∧ d ∈ SubD(Cr, Cd) p ∈ d P rms(Cr, Cd)∧ [r, p] ∈ / ASP AS (Cd)∧ r ∈ OBS (CARS , Cd) ∀d ∈ SubD(Cr, Cd), [r, p] ∈ / ASP AI (d) d ∈ SubD(Cr, Cd) ∧ [r, p] ∈ ASP AI (d)∧ ∀d0 ∈ SubD(r, d), [r, p] ∈ / ASP AI (d0 )
32
CreateDomain(d, s)
GrantAdmP rm(CARS , r, p, −)
RevAdmP rm(CARS , r, p, −) RevAdmP rm(CAR , r, p, d)
[CAR , delegate]
[CAR , delegate] [CAR , delegate]
Effect S OBS (CARS , Cd) ← OBS (CARS , Cd) {o}
OBS (CAR , d) ← OBS (CAR , d) U pdateChildT (Cd, Cr, d, o)
S
{o}
OBS (CARS , Cd) ← OBS (CARS , Cd) − {o} ASP AS (d) ← ASP AS (d) − {[o, p]} OBS (CAR , d) ← OBS (CAR , d) − {o} ASP AI (d) ← ASP AI (d) − {[o, p]} U pdateChildT (Cd, Cr, d, ⊥) S D ← D {d} AddChildT (Cr, Cd, d, ⊥) DeleteChildrenT (Cr, Cd, d)
ASP AI (Cd) = ASP AI (d)
S
{[r, p]}
S ASP AS (Cd) ← ASP AS (Cd) {[r, p]} ASP AS (Cd) ← ASP AS (Cd) − {[r, p]} ASP AI (d) ← ASP AI (d) − {[r, p]}
Table 11: Operations for domain, admin role and admin role-permission management
Admin functions CreateU ser(u) DeleteU ser(u)
RequiredPrms [CU , admin] [CU , admin]
Condition u ∈ OBJS(CU ) ∧ u ∈ / OBS (CU , Cd) u ∈ OBS (CU , Cd)
CreateDomainU ser(u, d)
[CAR , delegate]
d ∈ SubD(Cr, Cd)∧ u∈ / OBS (CU , d) d ∈ SubD(Cr, Cd)∧ u ∈ OBS (CU , d)
DeleteDomainU ser(u, d)
GrantU serRegRole(u, r) RevU serRegRole(u, r) GrantU serAdmRole(u, r, d)
33
RevU serAdmRole(u, r, d)
[CAR , delegate]
[CR , assignU ser] [CR , assignU ser] [CAR , delegate] [CAR , delegate]
u ∈ OBS (CU , Cd) ∧ [u, r] ∈ / SU A(Cd) ∧ r ∈ OBS (CR , Cd) [u, r] ∈ SU A(Cd) [u, r] ∈ / SU A(d)∧ d ∈ SubD(Cr, Cd) ∧ r ∈ OBS (CAR , d) [u, r] ∈ SU A(d)∧ d ∈ SubD(Cr, Cd)∧ r ∈ OBS (CAR , d)
Review functions Domains() AssignedU ser(r, d) AssignedRoles(u, d)
d = Cd ∨ d ∈ SubD(d) d = Cd ∨ d ∈ SubD(d)
RoleP ermission(r, d)
d = Cd ∨ d ∈ SubD(d)
RoleSchemaP ermission(r, d) Display(d, {c1 , ..cn })
d = Cd ∨ d ∈ SubD(d)
Table 12: Operations for user and user-role management and review functions
Effect S OBS (CU , Cd) ← OBS (CU , Cd) {u} OBS (CU , Cd) ← OBS (CU , Cd) − {u}, SU A(d) ← SU A(d) − {[u, r]|r ∈ OBS (CR , Cd)} OBS (CU , d) ← OBS (CU , d)
S
{u}
OBS (CU , d) ← OBS (CU , d) − {u}, SU A(d) ← SU A(d) − {[u, S r]|r ∈ OBS (CAR , d)} SU A(Cd) ← SU A(Cd) {[u, r]} SU A(Cd) ← SU A(Cd) − {[u, r]} SU A(d) ← SU A(d)
S
{[u, r]}
SU A(d) ← SU A(d) − {[u, r]} {d0 ∈ D|[−, d0 ] ∈ DescendantT (Cr, Cd)) {u ∈ OBS (CU , d)|[u, S r] ∈ SU A(d)} {r ∈ OBS (CR , d) OBS (CAR , d)| [r, d] ∈ SU A(d)} S {p ∈ PS (d) PA S (d)| [r, p] ∈ SP ASI (d) ASP AI (d)} {p ∈ PS (d) PA (d)| Map-based display of the reference space of d along with the contained features of type {c1 , ...cn }
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. In Proceedings 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 access 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 Proceedings 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. In Proceedings 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 Information Systems Engineering (WISE’05), pages 361–375, New York, USA, 2005. Springer-Verlag. 34
[8] M. Kumar and R. Newman. STRBAC - An approach towards spatio-temporal role-based access control. In Communication, Network, and Information Security, pages 150–155, 2006. [9] S. Aich, S.Sural, and A. K. Majumdar. STARBAC: Spatio temporal Role Based Access Control. In OTM Conferences (2) 2007: 1567-1582, 2007. [10] R. Sandhu, V. Bhamidipati, and Q. Munawer. The ARBAC97 model for rolebased administration of roles. ACM Transaction on Information Systems Security., 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. In ASIACCS ’07: Proceedings of the 2nd ACM symposium on Information, computer and communications 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 database system. ACM Trans. Database Syst., 1(3):242–255, 1976.
35
