1. WP6: Grid Authorization Service Review meeting in Berlin, March 8 th 2004 Marcin Adamski Michał Chmielewski Sergiusz Fonrobert Jarek Nabrzyski Tomasz Nowocień Tomasz Ostwald Poznań Supercomputing and Networking Center http://www.man.poznan.pl

2. Review Meeting in Berlin, March 8 th 2004 Grid Authorization Service General Requirements The authorization in real distributed and dynamic computing environments is still an open problem with specific set of requirements and constraints. Requirements cover mainly: Need for consistent and complete security policy in the context of the whole virtual organization (or grid environment), Appropriate mechanisms for performing authorization process taking into account a specificity of grid computing, Necessity of reliable and efficient components that could be considered as trusted ones. Usability in the context of users (primary goal) and administrators of grid environment (secondary goal)

3. Review Meeting in Berlin, March 8 th 2004 Grid Authorization Service Key Features The GAS is designed in order to fulfill various requirements of complex grid-based computing environments. It is considered as an trusted single logical point for managing security policy for virtual organizations. Support for different scenarios of using GAS, with possibility to apply them simultaneously within single virtual organization. It is assumed to be independent on specific technologies applied to build a grid infrastructure. Modular structure allows to introduce new modules for communication, database support, service management, integration with external security solutions.

4. Review Meeting in Berlin, March 8 th 2004 Grid Authorization Service The Architecture Overview Management components Administration of security policy (admin, user) Security policy database Storing of policy and maintaining its consistency Communication Components Communication with external services CORE Functionality Generating full or partial security policy Integration with security solutions

5. Review Meeting in Berlin, March 8 th 2004 Grid Authorization Service Current Status (update) Communication Debugging of components using GSI as well as gSOAP Policy Database Implementation of database interface for unixODBC Authorization Engine Support for RAD and RBAC Improved data structures Usage of restrictions Management GUI administration client Administration portlets (2)

6. Review Meeting in Berlin, March 8 th 2004 Grid Authorization Service Scheme of Presentation

7. Review Meeting in Berlin, March 8 th 2004 Grid Authorization Service Grid Security Policy The GAS enables describing applications, resources, services and users from the real world in a general form of subjects, objects and relations between them. Access rights (high granularity) may define very specific operations (ex. file append or delete database row) for specific objects (files, rows) and subjects (users, applications) Access rights must by defined in database prior requesting authorization decisions. Privileges may be defined with limitations and restrictions (time, source address) Access rights, subjects and objects may be clustered in groups and ordered in hierarchies reflecting real systems. In order to keep consistency of security policy, the GAS must manage all issues connected with privileges inheritance and avoiding incoherentness Dynamic privileges of subjects can be modeled by roles, which defines a set of access rights required in order to perform specific task (project manager). A role can be easily provided or removed to a user, also provided temporarily (replacement) or periodically (operator)

8. Review Meeting in Berlin, March 8 th 2004 Grid Authorization Service Grid Security Policies The GAS should be used to store all relevant data referring to VO security policy as well as security policy resource Security Policy for Virtual Organization (roles examples): Creator of Virtual Organization – creates a virtual organization, assigns Administrator to newly created VO. Administrator of Virtual Organization – defines groups of users, their roles in projects/organization, limitations and restrictions. User – uses a grid infrastructure, manages security policy in reference to all objects he owns. Security Policy for resource (roles examples): Administrator of Grid Resources – dis/connects resources from/to grid, registers services, assigns Administrator to newly added resource. Administrator of Resource - defines local security policy of resource in the GAS, decides who is dis/allowed to use it, selects Operators. Operator of Resource - maintains resource, installs software, perform updates, yet cannot change security policy of resource in the grid.

9. Review Meeting in Berlin, March 8 th 2004 Grid Authorization Service The Complete View

10. Review Meeting in Berlin, March 8 th 2004 Grid Authorization Service Summary Currently there exists a prototype of fundamental functionality Its main advantage is a flexibility allowing adaptation to different requirements of grid environments, as well as specific services Further works will cover: Extensions to components functionality Performance optimization and improvements of code security Integration with services developed in the GridLab project, Development of fixed scenarios, ready to be applied Progressive making resource components GAS-enabled