EGEE-II INFSO-RI Enabling Grids for E-sciencE EGEE and gLite are registered trademarks Update Authorization Service Christoph Witzig, SWITCH TMB April 7, 2009

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, Institutions Involved CNAF HIP NIKHEF SWITCH Note abbreviation: authZ = authorization

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, Service Components Administration Point: Formulating the rules through command line interface and/or file-based input Decision Point: Evaluating a request from a client based on the rules Enforcement Point: Thin client part and server part: all complexity in server part Runtime Execution Environment: Under which env. must I run? (UID, GID) Initial rules: Banning unbanning Pilot job Initial default deployment: All components on one host

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, On the CE Initial rules: Banning unbanning Pilot job Initial default deployment: All components on one host

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, The Plan Starting point: authorization study in EGEE-II –Identified need for consistent authorization in gLite –authZ service part of the DoW for EGEE-III Based on input from SA1/SA3 decided in spring 2008: –EGEE-III year 1: development of service –EGEE-III year 2: deployment of service –Reason: Service should be deployed within EGEE-III Presented deployment plan to TMB/GDB Feb 11, 2009

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, Proposed Deployment Plan (1/2) Deployment during EGEE-III Adoption during EGEE-III Guiding Principle: No big bang but gradually increasing use of authZ service through six self-contained steps

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, Proposed Deployment Plan (2/2) 1.glExec on the WN: Only change on WN is new version of glexec / LCMAPS Use of authZ service is a configuration option Installation of authZ service on one host through YAIM ALL policies are local (i.e. no remote policies) Only banning rules and enforcement of pilot job policy Note: No change to CREAM or lcg-CE (authZ policy only affects pilot jobs) 2.Grid-wide banning by OSCT OSCT offers centralized banning list to the sites

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, Initial Policies Banning of users (DNs), FQANs, CAs and VOs Pilot job policy two policies really (controlled entirely by the site) –Pilot job policy:  Site accepts pilot jobs  Primary FQAN has a specific role Question: Should the specific role be globally or configurable by the VO? oEx: FQAN = /atlas/role=atlas_pilot, /cms/role=cms_pilot –Payload job policy:  Pilot job policy  VO of pilot job submitter == VO of payload job submitter: currently not implemented –Proposals: 1.Pilot jobs are identified by “role=pilot”:  Question: Is that OK? 2.Constraints on VO of submitter and payload job will be added later?  Question: Is that OK?

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, Work since February (1/3) Initial contacts with CREAM and WMS developers Software development finished  Except GID obligation handling (needed for user switching) and new VOMS API (for FQAN handling) done by end of the week Testing has started at the sites of the four partner institutions –Focus on stability and throughput Note: “official” performance numbers should not be given by development team but by an external party (SA3)

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, Work since February (2/3) Stability: –3 day test with remote command line clients:  5 mio requests handled by 2 authz services  No reboots  No errors  Correct authorization decision was taken in all cases  No increase in memory over the three days –Long term test of distributing remote policies between two policy administration points (relevant ffor phase2 - OSCT ban list)  Several weeks

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, Work since February (3/3) Throughput: Hard to gauge - influenced by:  Hardware used  N simultaneous clients from M different hosts  Client startup time  Which time interval do you measure exactly?  Number of policies considered in the authZ service  Encryption used  Caching algorithm in use –Preliminary:  On 2.4 GHz dual core laptop with local blocking clients and few policies and no caching and no encryption: support 100 simultaneous connections with average response time of ms  Expect about 0.4 msec per additional policy rule  Note: this is not the performance you will see for glexec on WN Needs to be confirmed by independent group

Enabling Grids for E-sciencE EGEE-II INFSO-RI authZ service - GDB April 8, Next Steps Finish group mapping Finish documentation Testing, testing, testing… Expect to enter certification in 1-3 weeks