AN INTEGRATED FRAMEWORK FOR VO-ORIENTED AUTHORIZATION, POLICY-BASED MANAGEMENT AND ACCOUNTING Andrea Caltroni 3, Vincenzo Ciaschini 1, Andrea Ferraro 1, Antonia Ghiselli 1, Andrea Guarise 2 Giuseppe Patania 2, Rosario Piro 2, Gian Luca Rubini 1 [ 1) INFN-CNAF, Bologna, Italy; 2) INFN-TO, Torino, Italy; 3) INFN-PD, Padova, Italy] The Grid computing paradigm has introduced the Virtual Organization (VO) concept, which comprises a set of individuals and/or institutions having direct access to computers, software, data, and other resources for collaborative problem solving or other purposes. The sharing of resources is regulated by a context for Grid operations that allow discovering, accessing and monitoring, regardless of their physical location. This set of services acts as an intermediary between the physical resources and applications, it is called Grid Middleware. The EGEE middleware follows a service oriented architecture which will facilitate interoperability among Grid services and allow easier compliance with upcoming standard such as Open Grid Services Architecture (OGSA), that are also based on this principles. This architecture design is not bound to specific implementation of the services, the need is that they have to work together in a concerted way to achieve the goals of the end user. They can also be deployed and used allowing their exploitation in different contexts. Generally most services are managed by a VO, there is no requirement of having independent services instances per VO; for performance and scalability reasons service instances will in most cases serve multiple VOs. The main services, from EGEE point of view, are focused on this areas: security, Grid access, information and monitoring, job management, data management. In a production Grid the VO administrator has to manage the behavior of VO users. VOMS, G-PBox and DGAS are useful tools to do this. Introduction EGEE middleware This architecture shown in Fig.1 has a limitation regarding the authorization process, the user roles and capabilities (decided by a VO administrator using VOMS [1],[2]) cannot guarantee to access a specific service because, for example, a local resource administrator could have banned the access to all users for a limited time. In this case there is a conflict between a VO, which decide the user capabilities, and a local site where one ore more administrators manage resources owned by a local organization. This paper shows a proposal to extend this architecture using a policy framework (G- PBox) [3],[4] integrated with the VOMS and an accounting service (DGAS) [5] to have an homogeneous and VO oriented authorization process. VOMS, G-PBox, DGAS interactions 1/2 Fig.1 – EGEE middleware Grid Access Service API Access Services Auditing Authentication Authorization Accounting Package Manager Workload Management Computing Element Job Provenance Information & Monitoring Application Monitoring Metadata Catalog Storage Element File & Replica Catalog Data Management Security Services Job Management Services Data Services Information & Monitoring Services The EGEE grid middleware follows a service oriented architecture which allows a reliable interoperability among Grid services and an easier compliance with upcoming standards - such as Open Grid Services Architecture (OGSA) - that are also based on this principles. Extending the middleware Authentication Authorization Accounting Security Services Scope of VOMS, G-PBox, DGAS Job Management Services Fig.2 – Scope of VOMS, G-PBox, DGAS among Grid Services VOMS (Attribute Authority) G-PBox (Policy System) DGAS (Accounting System) VO Admin. Fig.3 – VO administrator task

2/2 VOMS and G-PBox together allow building and managing a smart Role-Based-Access-Control (RBAC) policy system, with VOMS providing attributes for groups and roles and G-PBox providing the permission profiles granted to the groups/roles defined by the VOMS. G-PBox and DGAS together allow the enforcement of policies regarding the accounting information for a user or a VO in its entirety. VOMS, G-PBox and DGAS communicate among each other using the GSI protocol and share the same sensitive data used by each tool. Figure 4 shows the strong interactions among the three components when a user submits a job. The first step is job submission(1) to the Resource Broker (RB), then the G-PBox plugin in the RB Policy-Enforcement-Point (PEP) asks(2) the VO G-PBox of the user about any policy concerning the user. These policies have been previously inserted by the user VO administrator or by a site administrator and propagated to the VO G-PBox). In the case of accounting policies, the VO G-PBox asks the VO DGAS for the required accounting parameters(3). The RB receives the answer from the VO G-PBox (5) and submits to the proper CE(6). In the CE a similar CE/G- PBox/DGAS process happens (7,8,9,10,11,12). VOMS G-PBox G-PBox plugin RB DGAS VO layer G-PBox plugin CE G-PBox DGAS Resource layer Fig.4 – User job submission One of the first use cases we analyzed was how to apply policies to the matchmaking done by the RB. The first such request we got was to have an RB capable of splitting resources in a series of classes, each with its own priority, and then split job assignment to resources based on such priority and the user's VOMS credentials. Needless to say, this job/resource match had to by dynamic, e.g. the credentials needed to access a specific class of resources had to be changeable without affecting in any way the configuration of the resources or of the broker. The chosen solution is to require a resource to publish a tag describing their class, in the information system, and then write policies associating a specific group/role combination to a class of resources. VOMS server Group A Group B Group C G-PBox Policies Group A : high and low priority CEs Group B : low priority CEs Group C : deny everywhere CE HIGH CE LOW RB Another PEP we implemented was a PEP for the Computing Element (CE), whose job was to take over grid user mapping to local accounts, based on policies. It’s implemented as an LCMAPS [6] plugin, which contacts G-PBox, sends it the credentials of the user and obtains a local account or pool account as a result, or a deny if the user is not allowed to submit jobs to the host. Fig.5 – User job submission The first experience of policies definition, related to different groups of a VO, and enforced by a Grid Resource Broker and checked by the CEs, demonstrated the effectiveness of such approach. Other policies, like CPU fair sharing and storage quota management, have been required and are going to be implemented. This framework is specific Grid independent and can be integrated with any service aiming to enforce policies in a distributed system where users and resource owner want to agree service level agreement and implement a production business model. [1] R. Alfieri, R. Cecchini, V. Ciaschini, L. dell'Agnello, A. Frohner, A. Gianoli, K. Lorentey, F. Spataro. VOMS, an Authorization System for Virtual Organizations. 1st European Across Grids Conference, Santiago de Compostela, February , [2] VOMS at INFN Authorization Working Group, [3] V. Ciaschini, A. Ferraro, A. Ghiselli, G. Rubini, R. Zappi, A. Caltroni. G-PBox: a policy framework for Grid environments. In Proceedings CHEP04, September [4] The G-PBox Home Page at INFN, [5] The Distributed Grid Accounting System (DGAS), [6] A local credential mapping service, G-PBox plugin CE DGAS plugin Grid user credential Local or pool account Fig.6 – User mapping Andrea Caltroni 3, Vincenzo Ciaschini 1, Andrea Ferraro 1, Antonia Ghiselli 1, Andrea Guarise 2 Giuseppe Patania 2, Rosario Piro 2, Gian Luca Rubini 1 [ 1) INFN-CNAF, Bologna, Italy; 2) INFN-TO, Torino, Italy; 3) INFN-PD, Padova, Italy] G-PBox DGAS plugin Conclusions and references A Resource Broker use case A Computing Element LCG compliant use case AN INTEGRATED FRAMEWORK FOR VO-ORIENTED AUTHORIZATION, POLICY-BASED MANAGEMENT AND ACCOUNTING