Grid computing enables computers on different networks to share their resources in an organized way. Authorized users can deploy the resources as if they were in the same organization. This resource sharing environment is called a Virtual Organization (VOs). To enable an open Grid to support resource sharing between multiple heterogeneous VOs, an authorization policy management framework is required to support authorization for VOs using heterogeneous authorization systems. The challenges include dynamic Grid memberships, VO trust relationships, and heterogeneous authorization systems.
Traditional authorization policy management frameworks work well in authorization for a single VO where the participating hosts agree to follow a global authorization system. However, they are not capable of authorization policy management for multiple VOs which deploys heterogeneous authorization systems.
To solve these problems in a loose-coupling way, we propose a dynamic, distributive and heterogeneous authorization policy management framework. The framework is called Dynamic Policy Management Framework (DPMF). DPMF groups VOs of the same authorization systems to form a virtual cluster. Authorization policy management is divided into inter-cluster heterogeneous policy management, and intra-cluster homogeneous policy management. Inside a virtual cluster, the workloads of policy management can be distributed among the VOs according to their trust relationships. The Conflict Analysis with Partial Information (CAPI) mechanism is developed to make authorization decisions in open environments without complete policy information. A Heterogeneous Policy Management mechanism is developed for DPMF to support inter-cluster heterogeneous policy management.
Grid computing enables computers on different networks to share their resources and services in an organized way. Authorized users can deploy the resources as if they were in the same organization. This environment aimed for resource sharing is called a virtual organization (VO).
Carpenter and Janson define three kinds of Grid environments according to their scopes, i.e., intra-grids, extra-grids, and inter-grids. Intra-grids refer to Grid environments which are internal to some existing organizations. Extra-grids are grids resulting from the pooling of resources across organizational entities that did not follow common architectural guidelines to deploy their IT infrastructures.
Inter-grids refer to Grid environments which are resulting from collaboration of extra-grids and/or intra-grids in the Internet. Inter-grids environments are open, dynamic, and consist of heterogeneous VOs. deAssuncao, et al. define that an inter-grid is a structure derived from internetworking grid islands (extra-grids). The figure below illustrates an example of an inter-grid environment which links multiple extra-grids.
An extra-grid, consisting of a single VO, applies coherent resource sharing mechanisms and an authorization system to enable organized resource sharing in the environment. On the other hand, an inter-grid may consist of multiple VOs. Each VO is considered to be an individual administrative domain in which authorization policies are set to control access to their resources. The access control constraints can include VOs, users, time, and other tailor-made conditions. In an inter-grid environment, a user may plan to perform tasks which involve access to resources on multiple VOs. To determine the privilege to perform the tasks, the user needs to request for authorization decision from a policy decision point (PDP). The PDP needs to retrieve all the policies related to the user and the resources, and then performs conflict analysis on the policies to make the authorization decision. The policy enforcement points (PEPs) would enforce the authorization decisions to allow or reject users to access the resources or services.
A VO is considered to be different from the classical organization in the way that the VO is composed of individuals from different organizations/institutions. Individuals in a VO agree to dynamically share resources or collaborate. The individuals are still governed by policies of their local organizations while they are also governed by policies of the VO. It is possible for an individual to participate in multiple VOs. An inter-grid environment is dynamic. VOs can join or leave the Grid environment throughout the Grid lifetime. Besides, an inter-grid environment is heterogeneous. The VOs may use different policy frameworks. The VOs may also provide different services and resources. In addition, the information of services and resources are distributed throughout the inter-grid environment. The dynamic, heterogeneous and distributive natures impose challenges to authorization policy management on Grids.
Security for Distributed Systems usually consists of the following services.
Authorization services require the support of authentication service to identify service requesters and system entities. But the functionalities of authentication and authorization are independent. Therefore deployment of different authentication services should not affect the effectiveness of an authorization service.
The DPMF research focuses on authorization policy management which is a kind of authorization service. DPMF is a novel framework for authorization policy management for multiple-VOs Grid environments. An authorization policy management framework handles specification of authorization policies, authorization process, and enforcement of authorization decisions. DPMF does not dictate a specific authentication service, but X.509 is recommended due to its popularity.
There are four major entities involved in a policy-based authorization process:
The IETF has defined a COPS (Common Open Policy Services) Protocol which is a policy control protocol. The protocol is based on a client/server model where there is a policy server. The policy server is termed as a PDP (Policy Decision Point) and the client is termed as a PEP (Policy Enforcement Point). The PEP sends requests of decision to the PDP, and the PDP replies to the PEP with its decision based on the policies stored in the policy server. The PEP is responsible to initialize a persistent connection to the PDP. The COPS protocol uses TCP for secure message transport. After receiving decisions from the PDP, the PEP has the responsibility to report to the PDP when it has finished performing the decisions locally. Optionally in the COPS protocol, there can be a LPDP (Local Policy Decision Point) used to make local policy decisions if PDP is absent. PEP may be able to make a local policy decision through its LPDP. However, the PDP is still the authoritative decision point at any time. This means that the decisions made by the LPDP need to depend on the policy information from the PDP. In the COPS protocol, the PDP must be granted access to all the information from the PEP to make a policy decision. RFC2904 defines three kinds of authorization sequences: agent sequence, pull sequence, and push sequence.
The Globus Toolkit developed by Globus Alliance is an open source software toolkit used for building Grid systems and applications. It is a community-based, open architecture, open source set of services and software libraries that support Grids and Grid applications. The toolkit addresses issues of security, information discovery, resource management, data management, communication, and portability.
Globus Toolkit Version 3 (GT3) deploys the Open Grid Service Architecture (OGSA) which is a framework aims to achieve these two criteria. The OGSA framework uses the WSDL (Web Services Description Language) to achieve self-describing, discoverable services and interoperable protocols, with extensions to support multiple coordinated interfaces and change management. OGSA define conventions and WSDL interfaces for a Grid service which is a (potentially transient) stateful service instance supporting reliable and secure invocation (when required), lifetime management, notification, policy management, credential management, and virtualization. OGSA also defines interfaces for the discovery of Grid service instances and for the creation of transient Grid service instances. OGSA adopts a common representation for computational and storage resources, networks, programs, databases, and other kinds of resources such that all of them are treated as services.
The Globus Toolkit Version 4 (GT4) additionally deploys the Web Services Resource Framework (WSRF) which is an infrastructure for building stateful Web Services. Being different from plain stateless Web Services, stateful Web Services can record state from one invocation to another invocation. This is required for general Grid applications. WSRF is a collection of four specifications: WS-ResourceProperties, WS-ResourceLifetime, WS-ServiceGroup, and WS-BaseFaults. The OASIS organization has approved the WSRF Version 1.2 specifications as an OASIS standard. With OGSA and WSRF, Globus Alliance defines standard specifications for building Grid services which can ally Web Services standards.
Dynamic Policy Management Framework (DPMF) is a hierarchical framework which aims to support the dynamic, distributive, and heterogeneous authorization policy management for inter-grid environments (i.e. grid environments of multiple VOs). The figure below illustrates DPMF's hierarchical architecture. There are three kinds of agents in the framework: Policy Agents (PA), Policy Management Agents (PMA), and Grid Information Agent (GIA). In DPMF, each VO needs to have a PA. The Grid Operator has a GIA. A PA needs to be able to access the VO's policy repository. If the VO already has a policy server, the PA is likely to be run on the PDP. Otherwise, the PA can be run on a node which has privilege to access the authorization policy repository in the VO. PAs of the same authorization system would form a virtual cluster. In each virtual cluster, one PA would be selected as the PMA when the old PMA withdraws membership. The selection scheme is to select the PA which is trusted by the largest number of other PAs. A PMA performs policy management for a homogeneous policy framework inside the virtual cluster, and heterogeneous policy management across different policy frameworks. The homogeneous policy management jobs can be distributed among the PAs. GIA is responsible to provide information to the PMAs for heterogeneous policy management. The information includes policy schema and account information of the VOs. All PAs need to provide the information to the GIA when they join the Grid environment. The GIA runs on a Grid Operator which exists permanently in the Grid environment.
The authorization model of DPMF follows the “push sequence”. To perform a task, a system user (service requester) needs to request the PDP for authorization of related services. After the PDP's decision making, if the authorization decision is positive, the PDP will grant an authorization token to the user. When the user is to perform the task, the user requests the target services by providing the authorization token. The figure below illustrates the authorization protocol in DPMF.
Policy management in DPMF includes the following two services:
One of the strengths of DPMF is the ability to distribute the policy management workload among the VOs. The degree of workload distribution depends on the average “percentage of trusted PAs”, which represents on average the number of PAs trusted by a PA in the virtual cluster. Figure 4 shows an illustration of job division of the authorization policy management tasks in DPMF. In the illustration, there are three virtual clusters. A PMA and its delegated PAs are responsible for homogeneous policy management of VOs inside the same virtual cluster. A PMA is responsible for heterogeneous policy management of VOs across different virtual clusters. The workloads of homogeneous policy management can be distributed among the PAs in the same virtual cluster.
In an open environment, some VOs may prefer to keep their policy information private. In DPMF, a trust relationship between VOs (represented by PAs) means the willingness of disclosing their authorization policies. Since a trust relationship is not compulsory in DPMF, some PAs may not be trusted by some other PAs.
During the manipulation of service authorization requests, if some of the involved PAs do not trust the PMA, the PMA is not able to retrieve certain policy information from the PAs. For example, a user from a VO plans to perform a task which involves interoperation with service providers from VOs in the same virtual clusters. So the PAs of the VOs request the PMA to perform a conflict analysis. In the example, all of the PAs trust the PMA except one. The PMA cannot retrieve the policy information from the untrustful PA. The PMA can only perform policy conflict analysis with policy information from the trustful PAs. To handle the problem, we have developed a conflict analysis mechanism which requires only partial policy information. It is called ``Conflict Analysis with Partial Information'' (CAPI).
The figure below illustrates the basic assumption in the CAPI mechanism: The more similar the policy owners are, the more similar their policies are. The service (policy owner) similarity is measured by comparing the attributes of the VOs, service providers, and services. The policy similarity can be measured by counting the number of matched policies between two policy sets. Therefore, the validation of the assumption is measurable and can be represented by the term ``correlation of service similarity and policy similarity'' (CoSP).
The figure below shows the main idea of the CAPI mechanism. The PMA collects policies and the policy owner attributes from trustful PAs, uses the collected information (policy templates) to generate substitutions for unknown policies when there are untrustful PAs in an authorization request. Then the PMA can perform conflict analysis with the known and substitution policies, finds out a set of conditions which can cause conflicts, sends the set of conditions to the untrustful VO for its checking, and finally makes an authorization decision. The generation of substitution policies is to find the policies where their policy owner attributes are similar to the untrustful PA's attributes
The CAPI mechanism is divided into three phases: pre-detection, detection, and post-detection. The figure below shows the flow of the CAPI mechanism in the three phases. The Pre-detection phase is to prepare the ``policy template database''. The Detection phase is to generate substitution policies to perform conflict detection and to conclude permission conditions. The Post-detection phase is to communicate with untrustful hosts to check the conflict detection results, and finally to make service authorization decisions.
One of the major objectives of DPMF is to manage authorization among VOs which deploy different authorization systems. An authorization system consists of an access control model and a policy model. The access control model defines how a user can get authorization to access a resource. The policy model defines how a resource owner constructs authorization policies to state the conditions for access to the resource.
DPMF supports heterogeneous authorization policy management by installing add-on modules on the heterogeneous Virtual Organizations (application domains). Through DPMF, a VO can provide services to users on other VOs which use different authorization systems. Simultaneously, the VO's users can access services on the other VOs. A prerequisite is that the VOs have a common authentication system, e.g. using X.509 certificates for user identities. The heterogeneous authorization policy management module in DPMF can be divided into two parts: Heterogeneous account mapping, and Heterogeneous policy mapping. Heterogeneous account mapping is to map accounts of users in a local VO to accounts on remote VOs or vice versa. This mechanism aims to deal with heterogeneous access control systems. By account mapping, users can access services on remote VOs as if they were local users on the VOs. Heterogeneous policy mapping is to map policies in heterogeneous policy models into the local one. This mechanism is required for the Policy Management Agent (PMA) when checking policy conflict and finding permission conditions for users' task requests.
The figure below shows a sample scenario of heterogeneous authorization policy management in DPMF. A user requests a task which is composed of services on a number of remote VOs. The number must be larger than or equal to two. In the example, the number of remote VOs is three. The user sends the authorization request to its PA. The PA forwards the request to the PMA in the same virtual cluster. The PMA requests related policies from the corresponding PAs (in different virtual clusters), and requests the ``account map'' and the ``policy schema map'' from the GIA. The PMA uses the ``account map'' to map the local user account to the remote user account in the policies; and uses the ``policy schema map'' to map the policies in heterogeneous models into policies in the local policy model. Then the PMA performs conflict analysis and concludes the permission conditions for the task. Finally the PMA makes an authorization decision for the request.
The figure below shows the use of policy schema maps for heterogeneous policy mapping. A policy schema map is a set of pointers from elements in the ``local policy schema'' to that in the ``meta-schema taxonomy''. There are two policy schema maps: one from local policy schema of virtual cluster A, and one from that of virtual cluster B. To map a policy from one policy model to another, the GIA looks into the meta-schema taxonomy for their common meta schema elements, and generates a schema map between schema elements of virtual clusters A and B. The PMAs of the virtual clusters can exchange policies using the map.
The DPMF can be facilitated by resource monitoring in two ways: (1) to ensure that the service providers have sufficient available resources to provide services, and (2) to distribute tasks to more available nodes for better load balancing of policy management tasks.
First, in heterogeneous and distributed environments, available resources can be dynamic. This can affect the quality of services available to users. An authorization policy management framework can be facilitated by using dynamic resource information as a decision factor. We prefer to enable users to add information of their required resources during service requests, instead of letting the service providers to add additional information in their authorization policies because the resource information is dynamic. By allowing users to define their required resources in a service request, we can extend DPMF to add a “resource requirement” information token. This enables service providers to provide services to users with their required resources.
Second, by learning about the available computational resources of the nodes in inter-grid environments, DPMF can distribute the tasks of policy management to more available PAs. DPMF has a mechanism to distribute the tasks of policy management to PAs of virtual organizations. By learning about the resource information of the PAs, the balancing of the task distribution can be improved.
We are concerned with the computer-based resources of a node, i.e. available CPU usage, available memory and available disk space. We define a piece of resource information to be: {node identity, available CPU usage, available memory, available disk}. In DPMF, each PA maintains a resource information list. The list records the resource information of the nodes in the VO. The PA periodically requests the nodes for their resource information, and updates the list according to the information received. On the other hand, the GIA of the inter-grid environment maintains a resource information list which records the resource information of the PAs in the environment. Similarly, the GIA periodically requests the PAs for their resource information, and updates the list accordingly.
We extend DPMF to take account of resource requirement. Our approach is to let users (i.e. service requesters) to define their resource requirement in their service requests. For example, a user wants to use a photo processing service to transform photos. The total size of the photos is around 10GBytes. So the user needs the service to provide sufficient disk space for storing the photos.
We have implemented a DPMF middleware on Globus Toolkit Version 4. The middleware is written in Java. It provides programs and authorization services to support the following DPMF functionalities:
The middleware package consists of the following five components:
The figure below illustrates the system design of DPMF for implementation on Globus Toolkit 4. The GIA runs the GIA Server and Client component. The PAs and PMA runs the PA Server and Client component and the Authorization service. The PAs, PMAs, and GIA communicate with each other through their Server and Client components by socket messaging.
The figure below shows the system diagram of DPMF implementation. In a Grid environment, a GIA maintains an information database for membership services and heterogeneous authorization services. In each VO of the Grid environment, there is a PA for authorization policy decision making. Each PA consists of server side components and a client. The server side components include an Information server and an Authorization Handler service. The Information server and the client are used for communicating with other PAs and the GIA. The Authorization Handler service is used for analyzing incoming authorization request to select appropriate authorization manipulation modules. When a VO aims to join the Grid environment, it establishes a PA. Then the PA requests GIA for Grid membership registration. Upon successful registration, the GIA sends the Grid's information to the PA, and the Grid Information states the virtual cluster information of the VO.
The DPMF middleware implementation is divided into two parts: GIA and PA. The GIA class provides functions for Membership Service, Account Mapping, Policy Mapping, and Grid Information Service. It maintains a Grid Information Database to store the information. The GIA has a ``GIA Information Transfer'' module for communication with PAs. Besides, the GIA has a ``Grid Membership Handler'' module for handling membership service operations.
The PA class provides functions for Policy Decision Making and PA Information Service. It maintains a PA Information Database to store the PA information, and a set of CAPI Information files for deploying CAPI mechanism. It can access to read the policy repository of the VO. The PA has a ``PA Information Transfer'' module for communication with other PAs and the GIA. Besides, the PA has a ``PA Authorization Handler'' module for handling authorization manipulations. There are four authorization manipulation modules which include Normal Authorization Manipulation, Delegation Authorization Manipulation, CAPI Authorization Manipulation, and Heterogeneous Authorization Manipulation.
Authenticated system users can request their PAs to request authorization. The DPMF middleware supports X.509 certificate for authentication. Every PA needs to apply for a X.509 certificate from a default Certificate Authority. In a VO, service users can apply for certificates at a local Certificate Authority. The users can generate proxy credentials using their certificates. When a system user plans to perform a task which collaborates multiple (more than two) services, the user first generates a ``authorization request'' file.
The figure below shows the GUI of the Request Generator which is used for system users to generate authorization requests. Then the user can execute a client program to send the authorization request to its PA, and to request a DPMF authorization service.
The service providers can define security policies for their services. In DPMF, there is no default policy model since the framework aims to manage heterogeneous policy models. In the experiments for the DPMF middleware, we use XML to define policy models with different schemas. For example, schema A can consist of Condition, Action, User while schema B can consists of Time, Permission, Target Identity. The figure below shows the GUI of a Policy Generator. Service providers can modify the code of the policy generator according to their policy schemas.
After receiving an authorization request, the authorization service at the PMA (or delegated PA) will manipulate the authorization request according to the DPMF system flow. It will call its PA Server and Client component to retrieve policies and other necessary information. Finally it will make an authorization decision.
The authorization decision is in the form of authorization token. The token will be sent to the service user and the corresponding service providers. When the user accesses the services, the user sends the authorization tokens to the target service providers to claim the authorization.
DPMF source package for Globus toolkit 4 [dpmfAuthz_package.tar.gz]
DPMF user's guide [dpmf_user_guide.pdf]
The work described in this paper was partially supported by the RGC Research Grant Direct Allocation (Project ID: 2050406).