1 / 11

Update Authorization Service

Update Authorization Service. Christoph Witzig, SWITCH ( christoph.witzig@switch.ch ) TMB April 7, 2009. Institutions Involved. CNAF HIP NIKHEF SWITCH Note abbreviation: authZ = authorization. Service Components.

janina
Download Presentation

Update Authorization Service

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Update Authorization Service Christoph Witzig, SWITCH (christoph.witzig@switch.ch) TMB April 7, 2009

  2. Institutions Involved • CNAF • HIP • NIKHEF • SWITCH • Note abbreviation: authZ = authorization authZ service - GDB April 8, 2009

  3. 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 authZ service - GDB April 8, 2009

  4. 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 authZ service - GDB April 8, 2009

  5. Proposed Deployment Plan (1/2) Guiding Principle: No big bang but gradually increasing use of authZ service through six self-contained steps Adoption during EGEE-III Deployment during EGEE-III authZ service - GDB April 8, 2009

  6. Proposed Deployment Plan (2/2) • 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) • Grid-wide banning by OSCT • OSCT offers centralized banning list to the sites authZ service - GDB April 8, 2009

  7. 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? • Ex: 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: • Pilot jobs are identified by “role=pilot”: • Question: Is that OK? • Constraints on VO of submitter and payload job will be added later? • Question: Is that OK? authZ service - GDB April 8, 2009

  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) authZ service - GDB April 8, 2009

  9. 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 authZ service - GDB April 8, 2009

  10. 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 100-150ms • 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 authZ service - GDB April 8, 2009

  11. Next Steps • Finish group mapping • Finish documentation • Testing, testing, testing… • Expect to enter certification in 1-3 weeks authZ service - GDB April 8, 2009

More Related