Model-based Refinement of Security Policies in Collaborative Virtual Organisations Benjamin Aziz1 , Alvaro E. Arenas2 , and Michael Wilson3 2
1 School of Computing, University of Portsmouth, Portsmouth, U.K. Department of Information Systems, Instituto de Empresa Business School, Madrid, Spain. 3 e-Science Centre, STFC Rutherford Appleton Laboratory, Oxfordshire, U.K.
[email protected],
[email protected],
[email protected]
Abstract. Policy refinement is the process of deriving low-level policies from high-level policy specifications. A basic example is that of the refinement of policies referring to users, resources and applications at a high level, such as the level of virtual organsiations, to policies referring to user ids, resource addresses and computational commands at the low level of system and network environments. This paper tackles the refinement problem by proposing an approach using model-to-model transformation techniques for transforming XACML-based VO policies to the resource level. Moreover, the transformation results in deployable policies referring to at most a single resource, hence avoiding the problem of cross-domain intereference. The applicability of our approach is demonstrated within the domain of distributed geographic map processing.
1
Introduction
Virtual Organisations (VOs) represent a common abstraction for describing computations and storage in a Grid environment. A VO is considered as a collaborative environment in which real organisations combine to offer applications and resources to users [1]. Such resources could be storage capabilities, software services or simply computational power represented as physical machines. A VO policy is a statement about the expected normal behaviour of applications, resources and users in the whole VO. A VO policy is usually written in terms of VO-wide concepts; possibly all the running applications, resources and users in the VO. VO policies are crucial to the correct operation of large-scale Grid-based VOs, dealing with issues of utilisation measurement, accounting, security etc [21]. Traditionally, a VO policy is seen as the collection of the individual resource policies. This view is both easily justifiable, in the sense that the VO consists in fact of the resources themselves, and passive, in the sense that no extra effort is required to manage and enforce VO policies that attempt to give a richer statement about the overall acceptable VO behaviour. More recently, research in security policies has moved on to the adoption of VO policies that express more than what the mere individual resource policies have been set up to express, as shown in [3]. This view is more interesting in the sense that it starts from the requirements of the VO itself, prior to its population with resources, rather than starting from the policy constraints of those resources.
A problem, however, that arises with this latter view is regarding the level at which enforcement of the VO policy is applied. There are at least two solutions: The first is to enforce the VO policy directly using a VO-wide Policy Enforcement Point (PEP). This case has the limitation of having a single centralised point of failure (such as operational or semantic failures). The second solution, which we adopt in this paper, is based on refining VO policies from their VO-wide representation down to their computational-level representation at individual resources [14]. This latter approach avoids the development of a centralised VO PEP but it is constrained by the limitations of the refinement algorithm and the fact that not all VO policies can be refined. We restrict our treatment in this paper to VO security policies, i.e. policies concerned with the access control of resources by users, that can be refined. Furthermore, we allow our refinement to be guided by predefined VO-Resource hierarchies in a similar manner to [17]. The paper is structured as follows. Section 2 introduces our case study, the processing of distributed geographical maps. Next, Section 3 presents some background information about the lifecycle of VO security policies, and discusses the relation between VO policies and resource policies. Section 4 describes the refinement of VO policies to their resource-level representation. Then, Section 5 shows the implementation of our refinement approach using model-based tools. Section 6 compares our work with others. Finally, Section 7 summarises the work and highlights future work.
2
A Case Study: Distributed Geographical Map Processing
We consider here a case study involving distributed geographical map processing [6]. In this scenario, shown in Figure 1, a user requests from the VO manager the creation of a specific multimedia artefact, such as a geographic map, a process which involves high levels of data storage and computation intensity [2].
Fig. 1. The Distributed Geographical Map Processing Workflow.
The VO manager initiates a worflow to execute the task leading to the production of the geographic map. This workflow consists of four main processes: – Editing: During the Editing process, users carrying out the task perform different computations on the data resource, in this case the map, to edit it. These task users
may belong to different administrative domains. The resource itself is protected by its own resource administrator and may have a local state indicating, for example, the current process of the workflow. – Merging: Once all the computational sub-tasks on the data are finished and submaps are produced, these are now merged into one draft map ready for validation. – Validating: This process commences when a complete draft of the map is ready, where the draft is validated to ensure that errors, incosistencies and anomalies are removed prior to the next process. – Publishing: Finally, once the map has been validated, it is ready to be published. We focus in this paper on four main concepts abstracted from this case study: – VO Processes: which include the various processes in the workflow, – VO Users: which include any users performing the VO processes, – VO Resources: which include the main VO resources such as data, in this case the geographic map, and computational power, – VO Environments: which express the state of the VO resources, in this case the flag indicating the state of the map. The above concepts represent high level business concepts, which despite the fact that it is possible to write policies in terms of these concepts, such policies will require enforcement at the high level of the business application itself. Beside the fact that high level concepts are not always tangible (e.g. a digital map does not exist outside the individual files or data sets containing its data), such a high level solution will introduce the need for a single centralised policy enforcement point that is capable of making decisions on behalf of all the resources in the VO. Instead, in our solution, the business policies are refined in terms of their computational concepts.
3
Background
In this section, we provide some background on the lifecycle of VO security policies explaining what we mean by VO policies and resource policies. 3.1
VO Policy Management
A lifecycle for the management of VO policies may consist of the following stages. – Generation of VO Policies from VO Requirements: During this stage, after the requirements of a VO have been gathered and analysed, these requirements are used to guide the creation of the VO policy. This could be done either by direct authoring or using policy generation tools (e.g. [12]). At this stage, VO policies can also be analysed for undesirable properties, such as conflicts or inconsistencies (see for example [13]). This stage is outside the scope of this paper. – Refinement of VO Policies to Resource Policies: Once the VO policy has been defined and analysed, it is then refined to a corresponding resource-level policy. This refinement yields a policy that may refer to multiple resources.
– Transformation to Deployable Resource Policies: Policies that refer to multiple resources are not suitable for deployment, since they reveal information to administrative domains about other domains. Therefore, a transformation is required to achieve deployable policies, which refer to at most one resource. Our focus mainly in this paper will be on the second and third stages. 3.2
VO Policies
There are many types of VO policies. Wasson and Humphrey [20] identify a few of these including security policies, resource provisioning policies and QoS policies. Our main focus here will be on security policies, which establish desirable security properties in a VO, such as acceptable access and usage behaviour, flow of information and integrity and availability of data. We define a VO policy as one that is written in terms of a VO alphabet. A metamodel of our VO alphabet is shown in Figure 2. The VO al-
Fig. 2. The VO Alphabet Metamodel.
phabet consists of entities such as VO Processes, VO Users, VO Resources and the VO Environments. A VO could consist of several processes composed or orchestrated in a workflow that determines the control flow logic for the execution of these processes. A workflow in this sense is the application itself. The VO may also have a number of users, that initiate and interact with its processes. A process requires VO resources to utilise during its execution within the global VO environment. A VO alphabet is domain-specific. For example, the following is a VO policy from the domain of our case study in distributed geographic map processing. Example 1. User Bart Simpson can edit the UK map belonging to National Geographic only between hours 13:00 and 14:00 on weekdays, for a maximum number of three times in each of these periods, and when the workflow is in the editing phase. 3.3
Resource Policies
At the resource level, a VO policy will express the desirable behaviour of the resource from the VO’s perspective and it will be a refinement of the global VO policy. The policy
must refer to the local resource alphabet, where the metamodel of one such alphabet as shown in Figure 3. This metamodel comprises entities such as resources, execution
Fig. 3. The Resource Alphabet Metamodel.
commands, user ids and computational environments. Each resource would have its own set of user ids that it controls access from. Commands are the decomposition of VO level processes and they execute on resources. Finally, a resource has its own environment, which may include the current time and date at the resource. The VO policy of Example 1 can be expressed in terms of this alphabet as follows: User abc1234 can read/write the topology/transportation datasets for the UK Map belonging to National Geographic only between hours 13:00 and 14:00 on weekdays, for a maximum of six times in each of these periods, and when workflow is in editing phase. Where user id abc1234 corresponds to the identity of Bart Simpson, read/write commands correspond to the editing process and the UK map consists of the topological and transportation data sets. Also, we assume that “. . . maximum of three times. . . ” is for each of the read/write operations (assumed to be equal to a total of six such commands). For the policy to be deployable, it will need to be transformed to the following two policies, since each file could have a different owner or administrator, even within National Geographic (e.g. belongs to a different department): User abc1234 can read/write the transportation datasets for the UK Map belonging to National Geographic only between hours 13:00 and 14:00 on weekdays, for a maximum of six times in each of these periods, and when the workflow is in editing phase. User abc1234 can read/write the topology datasets for the UK Map belonging to National Geographic only between hours 13:00 and 14:00 on weekdays, for a maximum of six times in each of these periods, and when the workflow is in editing phase.
4
From VO to Deployable Resource Policies
We discuss in this section the refinement of VO policies to their resource level representation. In order to understand the refinement process, we explain first what we mean by the notion of VO-Resource Hierarchies. 4.1
VO-Resource Hierarchies
In order to transform policies from the VO-level to the resource-level, one needs information about how the two levels are related to each other. In Su et al. [17], the authors define a resource type hierarchy, which is a directed graph expressing the topology of a VO in terms of its intermediate and most basic elements. The hierarchy also contains information about possible actions that can be applied to resources at each of its levels. The policy refinement then becomes a matter of instantiating policies at each level of the hierarchy. Here, we follow a similar, but more direct approach by assuming the presence of two levels only as in Figure 4, which we term a VO-Resource hierarchy.
Fig. 4. VO-Resource Hierarchy Metamodel.
The metamodel links the VO and resource alphabet metamodels of the previous sections, by defining VO processes as compositions of computational commands, VO users as compositions of user ids, VO resources as compositions of computational resources and VO environments as compositions of computational environments. Example 2. Let’s consider an example of this hierarchy metamodel inspired from case study of Section 2. Each of the VO processes is mapped to its set of computational level commands. For example, Edit may consist of the commands read, write, copy and delete of individual files. Merge could consist of the commands to copy and paste text
in order to construct the final draft of the document. Validate could also consist of the commands to read and write files in the final draft in order to correct any errors, and finally, Publish may consist of a command to print the final validated version. Similarly, a VO resource is decomposed in terms of the individual computational resources it comprises. Hence, a geographic map is decomposed into the individual files holding information about the topography, transportation and administrative boundaries in the map. VO users are mapped to computational level user ids. There could be many such ids each one of them local to the individual administrative domain or computational resource. For example, user Bart Simpson maps to user ids, abc1234, xyz0000 and fgh6789, each at the level of the individual resource. We also assume the presence of a system administrator who also have a user id on their local resources (root). Finally, VO-wide environment attributes are assumed to have definitions in terms of the computational level environment attributes local to each resource. Environment attributes could include the date and time of the day, the location of the resource if it is a mobile device, or any workflow status flags. 4.2
Policy Refinement
Based on the information provided in a VO-Resource hierarchy and given a VO policy, it is possible to define a policy refinement function, which takes VO-level policies expressed in XACML v2.0 and produces the corresponding resource-level policies also expressed in XACML v2.0. The refinement function can cater for all the elements of the XACML metamodel defined by OASIS [18]. In this model, XACML policies include rules on attributes of the subjects, resources and environments and their associated conditions as well as obligations that must be fulfilled if a policy is applicable. Example 3. We consider first a simple XACML policy from Example 1: x0 < /Element1 > / < Element1 > x < /Element1 >), (< Element2 >< AttributeValue > y 0 < /AttributeValue >< /Element2 > / < Element2 >< AttributeValue > y < /AttributeValue >< /Element2 >)] Where Element1 ∈ {Condition, Obligation} and Element2 ∈ {Resource, Action, Subject, Environment}. As for the variable x0 , it will have the value x0 = C(x) when Element1 is “Condition” and x0 = O(x) when Element1 is “Obligation”. Similarly, y 0 = R(y) whenever Element2 is “Resource”, y 0 = P(y) whenever Element2 is “Action”, y 0 = U(y) whenever Element2 is “Subject” and y 0 = E(y) whenever Element2 is “Environment”. Informally, the refinement applies a substitution to replace the resource, action, subject and environment attribute values in the VO policy with their values at the computational resource level taken from from the VO hierarchy relation as well as replace all the VO conditions and obligations by their corresponding computational siblings. The resulting policy now refers to resource concepts rather than the original VO concepts. Example 4. Going back to the policy of Example 3, applying our refinement function, T , yields the resource-level policy below.
