WP6: Grid Authorization Service Review meeting in Berlin, March 8 th 2004 Marcin Adamski Michał...
10
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
-
Upload
edward-jackson -
Category
Documents
-
view
212 -
download
0
Transcript of WP6: Grid Authorization Service Review meeting in Berlin, March 8 th 2004 Marcin Adamski Michał...
WP6: Grid Authorization Service
Review meeting in Berlin, March 8th 2004
Marcin Adamski Michał Chmielewski Sergiusz Fonrobert
Jarek NabrzyskiTomasz Nowocień
Tomasz Ostwald
Poznań Supercomputing and Networking Centerhttp://www.man.poznan.pl
Review Meeting in Berlin, March 8th 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)
Review Meeting in Berlin, March 8th 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.
Review Meeting in Berlin, March 8th 2004
Grid Authorization Service
The Architecture Overview
Management componentsAdministration of security policy (admin, user)
Security policy database Storing of policy and maintaining its consistency
Communication ComponentsCommunication with external services
CORE FunctionalityGenerating full or partial security policy
Integration with security solutions
Review Meeting in Berlin, March 8th 2004
Grid Authorization Service
Current Status (update)
CommunicationDebugging of components using GSI as well as gSOAP
Policy Database
Implementation of database interface for unixODBC
Authorization EngineSupport for RAD and RBACImproved data structuresUsage of restrictions
Management GUI administration clientAdministration portlets (2)
Review Meeting in Berlin, March 8th 2004
Grid Authorization Service
Scheme of Presentation
Review Meeting in Berlin, March 8th 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)
Review Meeting in Berlin, March 8th 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.
Review Meeting in Berlin, March 8th 2004
Grid Authorization Service
The Complete View
Review Meeting in Berlin, March 8th 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
