Efficient Integration of Fine-grained Access Control in Large-scale Grid Services Pietro Mazzoleni Department of Computer Science University of Milan,Italy Email:
[email protected]
Bruno Crispo, Swaminathan Sivasubramanian Department of Computer Science Vrije Universiteit, Amsterdam Email: {crispo,swami}@cs.vu.nl
Elisa Bertino Department of Computer Science and CERIAS Purdue University, USA Email:
[email protected]
Abstract
and access control need to be addressed. In Grid systems, authorization is traditionally bound to the notion of Virtual Organization (VO) [11]. A VO is defined as a community of subjects working towards a common set of problems. In such organization, access control policies (as well as subjects) are organized and applied at VO level (e.g., users belonging to ABC-Grid Project can access all resources). GSI, the security framework of Globus, is an example of such VO-based authorization approach [2]. While VO aims at supporting long-lived communities, it is not suitable for Grid infrastructures, such as desktop Grids [1], that require more dynamic and open infrastructures. In such infrastructures, users should be able to specify the security requirements that a resource must meet to be able to run their tasks. Similarly, resource owners should be able to specify the security constraints that must be satisfied by the user to use their resources. To address authorization issues in such dynamic Grid infrastructures, there are emerging solutions which leverage authorization towards Fine-grained Access Control (FGAC). With FGAC, each individual subjects as well as ad-hoc group of subjects can specify their own set of policies (e.g., by extending the global authorization policies set by the VO) to restrict access upon their own shared resources. All solutions proposed to support FGAC in Grid so far, consider policy evaluation and enforcement as an independent authorization service administered by each grid node. To ensure that tasks are scheduled only on nodes whose authorization policies are satisfied by the request, authorization services, at each node, match their policies with the user credentials each time a remote user contacts the node to run a new job. However, in case of Grid with a large number of nodes and each node being capable of specifying a fine-grained policy, such an approach is highly inefficient. If the re-
In this paper, we present a scalable authorization service, based on the concept of fine-grained access control (FGAC), for large-scale Grid infrastructures that span multiple independent domains. FGAC enables participating resource owners to specify fine-grained policies concerning which user can access can their resources under which mode. We argue that such an authorization service must be integrated with the resource broker service to avoid scheduling requests onto resources which do not authorize the user request. For this reason, we develop a novel resource broker service that integrates access control with resource scheduling. In our system, both resource owners and users define their resource access and usage policies. The resource broker schedules a user request only within the set of resources whose policies match the user credentials (and vice-versa). Since this process of evaluating authorization policies of resources and user, in addition to checking the resource requirement, can be a potential bottleneck for a large scale Grid, we also analyze the problem of efficient evaluation of FGAC policies. In this context, we present a novel method for policy organization and compare its performance with other strategies. Preliminary results show that the proposed method can significantly enhance performance.
1 Introduction Grid infrastructures enable seamless access and integration of resources in a world-wide scale by providing abstractions to resource sharing. Grid, as researchers envisage, must enable users to run their computational jobs on a remote set of resources, owned by somebody else, as if it were run locally. To realize this vision, issues such as trust 1
Grid Directory Service
source brokering service is unaware of the security constraints of the resources and the users, then it might allocate resources to an user who is not authorized to access them. This leads to inefficient repetitions of scheduling, decreasing the throughput of the scheduler, and increasing the node overhead (as each node has to perform evaluation that could be avoided) and communication overhead. Such an approach in scheduling jobs leads to inefficient resource allocation. In this paper, we present a novel resource broker that integrates the process of FGAC and resource scheduling. Our resource broker allows resource owners and users to specify their FGAC security policies. Subsequently, when a user submits a job request to the broker, the broker finds the set of resources whose FGAC policies match the user’s request by evaluating the FGAC policies of all nodes (across multiple domains). Since the number of policies to evaluate may be very high, policy evaluation algorithms need to be efficient. To address this issue, we explore and evaluate different strategies for organizing security policies of nodes in order to support a scalable policy evaluation engine. We demonstrate the scalability of our prototype policy evaluation engine with some preliminary performance results. The contributions of this paper are thus twofold. The first is the development of fine-grained access control system, specifically tailored to Grid environment, and tightly integrated with the resource scheduler. To the best of our knowledge, this is the first access control system with such features. The second is that we develop and evaluate different strategies for the evaluation of such fine-grained policies, and determine which is the most efficient one. The rest of the paper is organized as follows. Section 2 describes the system architecture and briefly introduces the methodology we propose to support FGAC in the Grid. Section 3 discusses the multi-dimensional schema according to which Local Policies are organized. Section 4 describes in details the resource broker functionalities and the policy evaluation process. Section 5 reports performance evaluation results concerning different policy organization strategies. Section 6 discusses related work and Section 7 concludes the paper and outlines future work.
RB
Administrative Domain 1 User N1
Global Policy (GP)
Address
VU
rb1.cs.vu.nl
GP1
HP
rb2.hp.com
GP2
Administrative Domain 2
...
RS
RS
N3
(1)
SE
SE
N2
User
(2)
RB
RB
Node
...
N3
(2) Forward user request to other RBs (whose GP matches the request) to see which node(s) satisfy the request.
N2 N1
User
User
(1) Get contacts of other Grid domains and their policies
RS
SE
...
RB
User
... N1 N2
N3
Administrative Domain 3
Figure 1. System architecture
2 System Architecture
responsible for handling incoming requests for resources in its domain. Each domain sets a global policy (GP) which is applicable to all its resources. For example, a GP for domain of corporate X can be “do not accept requests from corporate Y”. This model is realistic as each organization usually enforces certain security policies concerning access to its resources from external entities and users. In addition to the specification of a global policy for a domain, our system allows each individual node of the domain to specify a set of local policies (LPs) which apply only to its shared resources. However, it is essential to take into account the possibility that individual nodes might not want to expose their local policies to all Grid nodes. In our system, nodes publish their LPs within their domain only. The approach of storing LPs within its own administrative domain has the following advantages: (i) The controller of a domain can easily determine whether the various LPs conflict with its GP; (ii) every time a node updates its LPs, this update need not be sent to every other RB in the Grid. Each administrative domain runs a resource broker (RB), which is responsible for handling incoming requests to resources in its domain both from the users of its domain and other domains. All requests to resources in a domain can be authorized only by the domain’s resource broker (RB). The RB evaluates both the GP of its domain (for users from other domains) and LPs of its nodes to determine the set of nodes that authorize an user request.
2.1 System Model
2.2 System Components
The system architecture we propose is presented in Figure 1. As it can be seen from the figure, we consider a Grid infrastructure to consist of participating nodes from multiple administrative domains. An example of an administrative domain is a university, an organization, or even an ISP. Each administrative domain runs a resource broker service
In this section, we describe the salient components of the proposed system architecture. • Resource Broker Service (RB): It is the central component of our system. It supports two functions: access control and resource scheduling. Even though 2
these functions are supported by the same physical component, we consider them as supported by two separate logical components, Security Engine and Resource Scheduler. Note that our RB can support any existing resource scheduler and the issue of efficient resource scheduling [15] is orthogonal to the issue addressed in this paper.
the request meets also the LP of the involved node. The RB contacts the RBs of these domains to find the list of nodes in their domains that authorize the request. If such a node (or set of nodes) is found in one or more remote domains, then the request is forwarded to the remote domain’s RB to see if all resource-related constraints are met (for example if it has enough disk space, memory etc.). If both security and resource constraints are met, the RB can decide on which resource to schedule the user task based on any scheduling criteria (using the scheduling algorithm employed by its RS). Finally, the request is forwarded to the scheduled nodes which enforce the LP and run the job.
– Security Engine (SE). It is a logical component of the resource broker responsible for managing the security of nodes in its domain. SE supports two main functions. First, it is responsible for maintaining both GP and LPs of the nodes under its administration. Second, it is responsible for matching the credentials of the user (requesting accesses to its resources) and the LPs of its resources, to determining which node LPs’ will authorize the particular request. – Resource Scheduler (RS). This component is responsible for finding a set of nodes that meets the resource requirements of the user among the list of nodes that are authorized by the SE.
3 Authorization Policies In this section, we first present an overview of the notion of authorization policy. Then, we present various strategies according to which LPs and GP can be organized within a SE to support a scalable evaluation of LPs.
3.1 Policy Definition
• Grid Directory Service. RB of each domain publishes its global policies (GPs) in a publicly available Grid Directory Service (GDS). GDS maintains the list of administrative domains participating in the Grid, contact addresses of their RBs, and their GPs. GDS provides resource brokers (RBs) of each administrative domain with the contact addresses and GPs of other domains. GDS can become a potential bottleneck for infrastructures with large number of resources and user requests. In such cases, GDS can be implemented in a distributed/replicated fashion, similar to DNS or LDAP servers. However, GDS is not the focus of this paper and we assume techniques that are applied to improve scalability of directory services, such as multitier DNS architectures, can be applied here.
Authorization policies are logical expressions used for specifying the constraints defined by a Grid node (rather its resource owner) to restrict access on its shared resources from certain users or requests. With respect to the language used to specify policies, several alternatives have been proposed as a standard. For instance, XML-based languages such as XACML [20], SAML [7], WS-Policy [4] and Author-X [8], are all rich in semantics and flexible, thus making possible the specification of complex access control policies. The solution proposed in this paper does not rely on a specific formalism but is applicable to systems using any suitable policy language. In the following, we assume that a policy is composed by one or more rules. Each policy rule pol ruli is defined as a pair (pol expi , Ef f ecti ), where pol expi is a logical expression built using a policy attribute (e.g., User.Name, User.Affiliation, Resource.Amount, Time), and Ef f ecti is an action (Permit or Deny) to be executed when the policy expression is verified. In our system, we use XACML for defining FGAC policies. An example of an authorization policy written in XACML is given in Figure 2. The policy comprises two policy rules: ((T ime, T imeInRange = 8am . . . 5pm), P ermit), ((Af f iliation, StringEqual = U nimi), P ermit). These rules restrict access to users whose Affiliation is Unimi and to requests issued between 8am and 5pm. Policies adopt the “Deny Override combination algorithm. In this case, a request is denied as soon as at least one of the policy rules deny a request.
2.3 FGAC-Enabled Scheduling: An Example Now, let us consider an example of how a Grid user’s request is scheduled in our system. Each Grid user submits its request to the RB of its domain. If the request can be handled by local resources and if the LPs of the local resources meet the job request, then the request is scheduled to resources available in the local domain. If the request cannot be met by resources in the local domain, the RB retrieves from GDS the list of administrative domains, their contacts and GPs. Subsequently, it determines the list of administrative domains whose GP authorize the user request (step (2) in the figure). However, this does not mean that all nodes within these domains will authorize the request as the authorization is based on whether 3
tials of the user. If the number of user requests, the number of nodes, and/or number of policy expressions within a LP are high, then evaluating the policy rules of each node in a domain for each request can be a potential bottleneck. To reduce the policy evaluation time, we consider different strategies for organizing LPs and discuss their relative merits/demerits.
< /Resources > Unimi 08:00:00 17:00:00
1. No grouping (NoGroup): Here LPs are not grouped. For each user request, the LPs of each node are evaluated. 2. Group by LPs (LPGroup): Here nodes with same LPs are grouped together. For each request, evaluations are executed only at the group level. The intuition behind this heuristic is that if many nodes have same LPs then the number of evaluation to perform is reduced. A similar approach is used in Gangmatching [17].
Figure 2. Policy Example
3. Group by policy rules (RuleGroup): Here nodes using the same policy rules in the definition of their LP are grouped together. For example, consider two nodes that use the policy rule: Allow access to users whose affiliation=‘IBM’; then they are grouped together in an RuleGroup (RG) (i.e., in this case the RG, “affiliation=IBM”, has two nodes). This strategy is motivated by the fact that in fine-grained access control, it is more likely to find nodes that share at least fome same policy rules compared to nodes that specify exactly the same LP.
3.2 Policy Specification In our system, both resource owner and users can specify security requirements using FGAC-enabled authorization policies. The former specifies constraints on which user is authorized to access its shared resources for executing a task, while the latter specifies where its tasks can be executed, that is, which nodes are trusted for hosting a user’s process. Unlike conventional access control models, policies in our approach are not restricted to assigning rights to any specific user. Rather, policies are specified using subjects’ credentials (e.g., Name, Organization, Country) and additional attributes associated with the request (e.g., Time, amount of resource requested). An example of policy is “All nodes belonging to University of Milan can execute my applications from 8am to 5pm”. Note that this approach for the specification of FGAC policies is orthogonal to the authorization schema used. In fact, FGAC policies can be also defined by using roles (as in the case of Role-based Access Control (RBAC)), clearance levels (as in the case of Mandatory access Control), or group of subjects (as in the case of Discretionary Access Control). For instance, one could implement FGAC using RBAC by considering the role of a user as a specific user credential. Thus, one could express policies like “All subjects having the role of a database administrator can access the resource at any time”.
The first two strategies are quite straightforward, whereas the third one is described in more details in Section 5.
4 Resource Broker - Functionalities The RB is responsible for collecting node LPs, scheduling job requests and identifying the list of nodes whose LPs authorize a given request in addition to meeting the resource requirements of the job. Its activities can be organized into the following four main phases: Node registration, User registration, Job submission and Job request and execution. Node registration is executed when a node registers for sharing its resources in the Grid. In this phase, the node’s LP is collected and organized as described in Section 3. In the User registration phase, a user registers and obtains its certified credentials to run jobs within the Grid. During the Job submission phase, the RB analyzes a user request submitted to the Grid. It determines the lists of resources/nodes whose LPs authorize the request and among these nodes selects the subset of nodes that meets the resource requirements of the
3.3 Policy Organization Before scheduling a request to a node, RB needs to match the LP of each node in its domain with the creden4
(i) User Profile + Job Constratints (signed) (i) Regn: Node details LP
RB RB
User
User
Signed Certificates
(iv) List of nodes authorized and suitable for job (signed by RB)
(a) User Registration Phase
Interaction with RBs whose GP are met by user request
4.2 User Registration Phase
(b) Job submission Phase
(i) Submit job with certificates
In this phase, a user registers for using the Grid and performs an enrollment procedure to obtain a digital authentication certificate1 (i.e. X.509 [14]). The details of such enrollment, possibly involving a Certification Authority, are outside the scope of this paper. For our purpose, it suffices to say that at the end of the registration users have a digital certificate to prove their identity to the RB and to the resource owners. Similarly and optionally, authentication can be extended to nodes at their registration phase. Node authentication has the advantage that users and resource owners can mutually authenticate by using such certificates, as we will see in the job submission phase. Finally, the RB also has a digital authentication certificate, both for mutual authentication between users and RB, and more importantly for resource owners to verify authorization statements sent by users with their job request as we will see in the job submission phase. Since LPs state constraints on user credentials, users must submit the information (called user-profile) necessary for the policy evaluation when issuing an access request. If the information into the user profile validates the GP as well as the LP of a node, the request is authorized, otherwise it is rejected. Based on the nature of the information collected into a user profile and the types of request issued by the user, we distinguish between:
(ii) Validate certificates
N1 (iii) Accept/Deny
User
though some optimizations are possible in order to reduce the re-computation overhead, we did not explore this problem for now.
(Node authorized and considered suitable for job by RB)
(c) Job Running Phase
Figure 3. Different phases: User registration, Job submission and execution
job. Finally, during the job submission phase, an user submits the job to the node selected by the RB. These phases are illustrated in Figure 3. In this section, we describe the activities that are executed in these phases and describe their implications on the different kinds of policy organizations proposed in Section 3.3.
4.1 Node Registration Phase Each new node, that is willing to share its resources in the Grid, registers with its local RB by publishing the resource information and its LP. The RB first verifies if the node’s LP conflicts with the global policy (GP). If conflicts arise, the node’s LP is rejected. If no conflicts arise, the RB organizes the node policy according to one of the policy organizations described in Section 3.3. In case of “No Grouping” and “Group by LP” strategies, the process is quite simple. For example, in the case of Group by LP, SE verifies if there exists another LP matching the one specified by the new node. If this is the case, the two LPs are grouped together; otherwise, the new policy is stored separately. More interesting is the “Group by policy expression” strategy. In this case, RB decomposes LP into policy rules and organizes each rule into the RGs by matching policy rule expression with RG expressions. Note that the process used to identify the type of relation between RGs and rule expression is straightforward given that it requires comparing two values (for single values credentials such as User. Affiliation), simple inequalities (e.g. maximum resource requested) or at most ranges of values (e.g. Time). Once registered to the RB, the node becomes available for executing tasks. In case the node changes its policy, it is required to communicate the changes to its local RB which will re-execute the node registration process. Al-
• Static profile: It contains attributes whose values do not change for the job requests issued by the user. Examples of such attributes are User.Name, User.Affiliation. • Dynamic profile: It contains attributes whose values may change for each request, such as Condition.Time, User.IP, Resource.Amount. When a new user registers with the Grid, RB collects the user’s static profile and performs a preliminary evaluation to determine the list of nodes whose LPs can be completely evaluated using information available from the static user profile alone. Such list of nodes will authorize or reject all requests from that user without requiring further rule evaluation at job submission. We call this list as node-list. This list can be cached and used for future requests. The activities executed to extract such list are similar to the ones the 1 We recall here that a digital authentication certificate is a digitally signed statement asserting the authenticity of the binding between a public key and a particular identity/identifier. This statement is signed by a party that must be trusted by both the entity to which the certificate is issued and any entity that may need to verify a statement signed by the certified key.
5
4.4 Job Request and Execution Phase
RB performs for each job request which are described into the next section. Note that since each RB can access LPs of nodes only in its domain, node-list comprises nodes only from its domain.
This is the phase where a user submits the job to the node selected by the RB. Initially, the user and the node mutually authenticate and establish an authenticated channel [12]. All subsequent messages are sent over this channel. Then the user sends the job request followed by the RB-signed list of nodes that authorize its job execution. Once the node receives the request, it can use one of the following two strategies based on whether the node trusts the RB or not. If the node trusts the evaluation decision made by the RB, then the node authorization service simply checks that it is in the list of selected nodes and verifies the authenticity of the list by verifying the RB signature. If both checks are successful, it sends an acceptance message to the user. If the node does not trust the RB evaluation, the node authorization service can simply perform its own evaluation of the user request against its own local policy and send the acceptance/denial answer to the user. Of course the latter strategy is less efficient and requires the user to submit with the job request also the job constraints. If the user receives the acceptance message, then the user can submit the job for execution to the node. For clarity of explanation, we use a different communication round for each message. In practice two rounds will be enough to implement this phase.
4.3 Job Submission Phase This phase concerns the process of scheduling a job request. Here, the RB receives a user request and finds a suitable set of nodes whose LPs and resource constraints meet the user request. For efficiency reasons, we assume that the user and the RB mutually authenticate not by using certificates but using weaker and more efficient methods such as IP-based or password-based authentication 2 . For a given job request, the RB first checks to see if the user request can be met by nodes in its node-list. If one or more nodes in this list meet the resource requirements of the request, then the job is scheduled. Otherwise, the RB takes the dynamic user profile as input from the user and generates the list of compliant nodes by matching the local policies of its node and the user profile. The process of determining which node’s LP match a job request is different based on the type of organization adopted for the nodes. In case of “No Grouping” and “Group by LP” strategy, the RB takes all nodes’ LP (or group of policies in case of Group by LP) and sequentially evaluates their policy rules. On the other hand, if policies are grouped by Policy Expression, the process is slightly different. Here, the RB first identifies the set of RGs which can validate the request. This is determined by matching the user profile against the policy rule expression of each RG. The list of nodes that authorize the job request, obtained as a result of any of the above strategy, is passed by the SE to the RS. The RS uses this list as a input for its scheduling algorithm. The result is the list of nodes selected by the scheduler as the ones in which the task will run This list is then signed by the RB and returned back to the user. As noted earlier, RB of a given domain can contact RBs of other domains to see if the latter’s resources can serve a given job request. A naive way to do this is to send the job request to all the RBs registered with the GDS. This can potentially increase the load of each RB and the communication overhead. Hence, instead of asking all RBs registered with GDS, the RB forwards the job request only to the subset of RBs whose GP authorize the job request. Subsequently, the RBs of these domains run the the algorithm desctribed above for the job request and return a list of nodes that authorize the request.
5 Performance Evaluation To study the performance of different policy evaluation schemes, we built a prototype of the policy evaluator. We used XACML as the policy language. The prototype was built using Java and SUNXACML [20]. The experiments were conducted on Pentium4 3.2 Ghz, Windows 2000 machine. The runtime JVM for the processes involved was JRE 1.4.2. We tested the performance of different grouping mechanisms for 5000 LPs. Each LP is assumed to be composed of three rules. Among these three rules, we fix the attribute values for two of them. For the third one, we vary the values for a given percentage of nodes. Thus, for example if we vary the attribute values of 1000 LPs, then the similarity among LPs is fixed at 80%, as 4000 LPs have the same policy rule values. This allows us to measure the impact of similarity in LPs such that we can vary the overall percentage of similarity among LPs. In our experiments, we study the performance of different grouping schemes for various similarity values. Figure 4 reports the performance of each strategy for different values of similarity. As we can see from the figure, the evaluation time of NoGroup strategy is constant and is not affected by the similarity among LPs, as it does not perform any grouping. However, the evaluation time of LP-
2 Of course we can always plug-in the SSL/TLS protocol based on digital certificate if necessary.
6
12
8
NOGroup
6
LPGroup
4
RuleGrup
Time Sec.
Time Sec.
10
2
12 10 8 6 4 2 0 0%
0 0%
20% 40% 60% 80% 100%
% of equal policies over a total of 5000 all with 1 rules
20% 40% 60% 80% 100%
% of equal policies over a total of 5000 w ith 3 rules
Time Sec.
Figure 4. Performance of different strategies for different similarity values Group and RuleGroup strategies decrease with increase in similarity values. Between these two, the RuleGroup strategy performs better. This because unlike LPGroup which groups two nodes with same policies, RuleGroup employs fine-grained grouping and groups nodes with same policy rules. Thus, while evaluating a job request, RuleGroup does not have to evaluate the complete LP of each node. Furthermore, as in our tests, the average number of nodes with same policy rule is higher than average number of nodes with same LP, RuleGroup performs better than LPGroup. We varied the number of policy rules used in a LP, and studied the performance of these three strategies. The results are given in Figure 5. Again, the results are similar to the previous experiments and show that RuleGroup strategy performs better in all cases. Even though the evaluation results reported here are preliminary, we believe this is a promising starting point to study the process of RuleGroup strategy in detail.
14 12 10 8 6 4 2 0 0%
20% 40% 60% 80% 100%
% of equal policies over a total of 5000 all with 4 rules
Figure 5. Performance of different strategies for LPs with 1 and 4 policy rules authorization certificate, often using X.509, and submits the request to the resource owners service. (ii) The service extracts the user identity and passes it to the authorization service, which (iii) evaluates the policies and decides upon authorization. This approach is in line with ours. We do not propose an alternative solution to either specify or enforce authorization policies. Instead, we propose to integrate policy evaluation with scheduling in case of FGAC in large Grids. There is a clear differences between the tasks carried out by our RB and the ones provided by the OGSA framework. OGSA is in charge of publishing node’s policies and authorizing the requests once the service has been selected, whereas the RB is in charge of taking a request, determining the nodes more suited for its execution, and finally reporting the results to the user. Systems such as Condor [17] use class-ads to express resource attributes and perform matches between job requests and available resources. The primary focus of these approaches is on developing resource management algorithms and thus they handle access control only during job execution. In our work, we argue that access control should be considered also in the job submission phase. Our focus is on building a security component that performs match-making between grid user requests and FGAC policies of resources in the context of job scheduling. In [3], authors use the notion of numerical trust metric to integrate trust into resource management. The fundamental limitation of their approach is that even though the idea of
6 Related Work GT3 (Globus Toolkit 3) defines security implementation by using Open Grid Service Architecture - OGSA - [10]. With OGSA, Grid can use Web Service techniques to specify, publish and enforce security policies. Each Grid node can now use standard authorization languages such as WSPolicy [4] and XACML [20] to specify its policies. A recent implementation of those methods in Grid is CAS (Community Authorization Services) [19] which is built on top of GSI and allows resource providers to maintain ultimate authority over their shared resources. Other solutions such as PERMIS [5], PRIMA [16], VOMS [9] also support FGAC. Those systems differ for the language used to specify authorization (i.e., SAML, XACML, or ad-hoc language), the authorization model (i.e., pull, push, or by agent), and functionalities (i.e., support for PDP - Policy Decision Point Decision only or both PDP and Policy Evaluation Point). However, they all use the following basic model [13, 6]: (i) the user obtains the 7
reducing and simplifying the notion of trust to a number is appealing, we argue that in real world many aspects of trust are qualitative rather than quantitative. The concept of fine-grained authorization for resources is also analyzed in [18], where the Akenti tool is used to perform the access control. Their work focuses on the job execution phase during which users with different privileges are allowed to perform different job management functions. We believe that our work complements their tool as each of these handle different phases of a Grid lifecycle.
[6]
[7] [8]
7 Conclusions and Future Work
[9]
In this paper, we have described the design of a novel resource broker for large scale Grid services. The broker supports and integrates the concept of fine-grained access control and scheduling into a single component. Such an integration at the resource scheduling layer avoids situations in which a user finds out that he/she is not authorized to execute his/her job on the resource allocated by the scheduler. For Grid infrastructures, with a large number of nodes and with users being able to specify their own security constraints, the process of policy evaluation needs to be efficient and scalable. As a consequence, we have also discussed and evaluated different strategies to perform scalable evaluation of FGAC policies. By our preliminary analysis, we have concluded that existing policy organization schemes can be improved by adopting a Group by policy rules organization. However, more research needs to be carried out dealing with techniques for the scalable evaluation of FGAC polices. As future work, we plan to integrate the broker with existing resource schedulers in a desktop Grid infrastructure such as BOINC [1]. Acknowledgements The work of Elisa Bertino is partially supported by the National Science Foundation NSF under the Project ”Collaborative Research: A Comprehensive Policy - Driven Framework For Online Privacy Protection: Integrating IT, Human, Legal and Economic Perspectives”, by an IBM Fellowship, and by the sponsors of CERIAS.
[10] [11]
[12]
[13] [14]
[15]
[16]
[17]
[18]
[19]
References [20] [1] Berkeley open infrastructure for network computing, http: //setiathome.ssl.berkeley.edu/. [2] Grid security infrastructure, http://www-unix. globus.org/toolkit/docs/3.2/gsi/index. html. [3] F. Azzedin and M. Maheswaran. Integrating trust into grid resource management systems. In International Conference on Parallel Processing (ICPP’02), Vancouver, B.C., Canada , August 2002. [4] M. BEA, IBM and SAP. Web servies policy language (wspolicy). 2002. [5] S. Brostoff, M. A. Sassea, D. Chadwick, J. Cunningham, U. Mbanaso, and O. Otenko. Rbac what? development of a
8
role-based access control policy writing tool for e-scientists. Workshop on Grid Security Practice and Experience, pages V21–38, July 2004. D. Chadwick and O. Otenko. A comparison of the akenti and permis authorization infrastructures. proceedings of the ITI First International Conference on Information and Communications Technology (ICICT 2003), pages 2–26, 2003. O. S. S. T. Committee. Assertions and protocol for the oasis security assertion markup language (saml), Sept 2003. E. F. E. Bertino, S. Castano. On specifying security policies for web documents with an xml-based language. SACMAT01 ACM Symposium on Access Control Models and Technologies, 2001. R. A. et al. (EDG Security Co-ordination Group). Managing dynamic user communities in a grid of autonomous resources. Proceedings of Computing in High Energy and Nuclear Physics, 2003. S. T. et.al. Open grid services infrastructure (OGSI) version 1.0, 2003. I. Foster, C. Kesselman, and S. Tuecke. The anatomy of the Grid: Enabling scalable virtual organizations. Lecture Notes in Computer Science, 2150, 2001. I. T. Foster, C. Kesselman, G. Tsudik, and S. Tuecke. A security architecture for computational grids. In ACM Conference on Computer and Communications Security, pages 83–92, 1998. A. framework and G. F. W. G. mechanisms GRID [AuthZ]. Conceptual authz framework and classification, 2003. R. Housley, W. Polk, W. Ford, and D. Solo. Internet x.509 public key infrastructure certificate and crl profile, RFC3280 2002. K. Krauter, R. Buyya, and M. Maheswaran. A taxonomy and survey of grid resource management systems for distributed computing. Software, Practice and Experience, 32(2):135– 164, 2002. M. Lorch, D. Adams, D. Kafura, M. Koneni, A. Rathi, and S. Shah. The prima system for privilege management, authorization and enforcement in grid environments. 4th Int. Workshop on Grid Computing - Grid 2003, November 2003. T. Tannenbaum, D. Wright, K. Miller, and M. Livny. Condor – a distributed job scheduler. In T. Sterling, editor, Beowulf Cluster Computing with Linux. MIT Press, October 2001. M. Thompson, A. Essiari, K.KIeahey, V. Welch, S. Lang, and B. Liu. Fine-grained authorization fo job and resource management using akenti and the globus toolkit. Sept 2003. F. C. K. L. P. S. T. V. Welch. The community authorization service: Status and future. 2003 Conference for Computing in High Energy and Nuclear Physics, 2003. XAMCL and O. S. S. T. Committee. eXtendible Access Control Markup Language (xacml) committee specification 1.0, Feb 2003.
