EGEE-III INFSO-RI Enabling Grids for E-sciencE EGEE and gLite are registered trademarks The new gLite Authorization Service Alberto Forti, INFN for the EGEE AuthZ group. Workshop CCR and INFN-GRID. May 14th, 2009, Palau.

Enabling Grids for E-sciencE EGEE-III INFSO-RI Outline Introduction Short Description of the Service –The PAP component Deployment plan Status Summary

Enabling Grids for E-sciencE EGEE-III INFSO-RI Institutions Involved CNAF HIP NIKHEF SWITCH Deployment plan –Devised together with SA1 / SA3 –Reviewed and endorsed by TMB Note abbreviation: authZ = authorization

Enabling Grids for E-sciencE EGEE-III INFSO-RI Introduction: Which Problems Are We Trying to Solve? Different Services use different authorization mechanisms Site administrators must configure the authorization for each service at their site separately –Consequence 1: At a site, there is no single point to ban users/groups of users for the entire site –Consequence 2: many site administrators don’t know how to ban users –There should be a command line tool for banning and un- banning users at a site There is no central grid-wide banning list to be used during incidents –Consequence: Urgent ban cannot be taken for granted during incidents

Enabling Grids for E-sciencE EGEE-III INFSO-RI Introduction: Which Problems Are We Trying to Solve? Site administrators do not have simple debugging tools to check and understand their authorization configuration Sites cannot publish their complete authorization policy to the outside world –Currently only assignment of FQANS (experience of DENY tags) –Note: Fixing this problem does not mean that sites MUST publish their authorization policy No monitoring on authorization decisions

Enabling Grids for E-sciencE EGEE-III INFSO-RI Introduction: Benefits of the Authorization Service (1/2) Main benefit within EGEE-III: –Addressing the above list of short-comings In addition: –Resistance to failure and simple means for scaling the service  Flexible deployment model  No dependency on a shared file system  High availability option –Client component is very lightweight  Small amount of code  Few dependencies (especially on WN)  Portability: support on other OS and languages easy

Enabling Grids for E-sciencE EGEE-III INFSO-RI Introduction: Benefits of the Authorization Service (2/2) In addition (cont.): Enables/eases various authorization tasks: –Banning of users (VO, WMS, site, or grid wide) –Composition of policies – CERN policy + experiment policy + CE policy + OCST policy + NGI policy=> Effective policy –Support for authorization based on more detailed information about the job, action, and execution environment –Support for authorization based on attributes other than FQAN –Support for multiple credential formats (not just X.509) –Support for multiple types of execution environments –Virtual machines, workspaces, … –Nagios plug-ins provided for monitoring of service

Enabling Grids for E-sciencE EGEE-III INFSO-RI The Authorization Service (1/3) Service components –Policy Administration Point (PAP)  The repository for store, curating, and composing policies  Hides XACML complexity –Policy Decision Point (PDP)  Given a request, evaluate the appropriate policy, retrieve execution environment, and return result  XACML based policy evaluation engine –Policy Enforcement Point (PEP)  Makes request to PDP, may operate on execution environment data –Execution Environment Service (EES)  Given a request, an effective policy, and a decision it determines the appropriate execution environment

Enabling Grids for E-sciencE EGEE-III INFSO-RI The Authorization Service(2/3) Administration Point (PAP): Formulating the rules through command line interface and/or file-based input Decision Point (PDP): Evaluating a request from a client based on the rules Enforcement Point (PEP): Thin client part and server part: all complexity in server part Execution Env. (EES): Under which env. must I run? (UID, GID) Initial default deployment: All components on one host PAP PDP EES PEPd Server part Client part gLite Authorization Service PEP

Enabling Grids for E-sciencE EGEE-III INFSO-RI The Authorization Service(3/3) Provides: –CLI for policy administration (hides XACML from sys admin) –CLI for policy evaluation (in C and Java) –Thin client  C and Java API  Few dependencies allow easy implementation of other language bindings –LCMAPS plug-in (--> glexec) –Component endpoints for monitoring (nagios plugins provided) Documentation: –

Enabling Grids for E-sciencE EGEE-III INFSO-RI The PAP component Developed by INFN Provides: –Tools for authoring, storing and managing policies used by the Authorization Service  Hides the complexity of the XACML from the users –A policy distribution mechanism –An authorization layer that defines “who can do what” on the PAP  who can write policies, which other paps are trusted, etc... Command Line Interface: “pap-admin” –Provides scriptable access to all the PAP functionality  Policy management  Policy distribution  PAP Authorization and configuration

Enabling Grids for E-sciencE EGEE-III INFSO-RI PAP: policy management (1/2) Policy management: # pap-admin --help usage: pap-admin [global-options] [options] [args] … Policy management: ban un-ban (uban) add-policy (ap) add-policies-from-file (apf) update-policy-from-file (up) remove-policy (rp) remove-all-policies (rap) list-policies (lp) move (mv) …

Enabling Grids for E-sciencE EGEE-III INFSO-RI PAP: policy management (2/2) Policy composition: –PAP CLI commands (e.g. banning, unbanning, etc) –Simplified policy language Policies are listed using the “simplified policy language” syntax resource “.*” { action “.*” { rule deny { dn=“/C=IT/O=INSTITUE/OU=Personal Certificate/L=DEP/CN=Nome Cognome” } } action “job-submission” { rule permit { pfqan=“/dteam/group_test” } } # pap-admin ban dn=“/C=IT/O=INST/OU=Personal Certificate/L=DEP/CN=Nome Cognome” # pap-admin un-ban dn=“/C=IT/O=INST/OU=Personal Certificate/L=DEP/CN=Nome Cognome”

Enabling Grids for E-sciencE EGEE-III INFSO-RI PAP: distribution management (1/2) Distribution management: # pap-admin --help usage: pap-admin [global-options] [options] [args] … Distribution management: ping add-pap (apap) remove-pap (rpap) update-pap (upap) list-paps (lpaps) enable-pap (epap) disable-pap (dpap) refresh-cache (rc) get-paps-order (gpo) set-paps-order (spo) get-polling-interval (gpi) set-polling-interval (spi) …

Enabling Grids for E-sciencE EGEE-III INFSO-RI PAP: distribution management (2/2) Import policies from a remote PAP: Override imported policies with local policies: # pap-admin add-pap OSCT osct.test.cnaf.infn.it \ “C=IT/O=INST/OU=HOST/L=DEP/CN=osct.test.cnaf.infn.it # pap-admin set-paps-order OVERRIDE_OSCT OSCT default

Enabling Grids for E-sciencE EGEE-III INFSO-RI PAP: authoriation management Authorization management: Allow the admin group of the VO dteam to write and list local policies: Allow the user Alberto Forti to perform any operation: # pap-admin --help usage: pap-admin [global-options] [options] [args] … Authorization management: list-acl (lacl) add-ace (aace) remove-ace (race) … # pap-admin add-ace “/dteam/admin” POLICY_READ_LOCAL|POLICY_WRITE # pap-admin add-ace “/C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Alberto Forti” ALL

Enabling Grids for E-sciencE EGEE-III INFSO-RI TMB 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-III INFSO-RI TMB Deployment Plan (2/2) Integration into CREAM: –Design: decided –Begin implementation: Early summer Phase 4: Integration into WMS for authorization –Initial design discussions –Intends to leverage against CREAM integration –Begin implementation: Late summer –Phase 5 not in EGEE-III Phase 6: Integration into DM –Focus on banning policies –Initial discussions held

Enabling Grids for E-sciencE EGEE-III INFSO-RI Status PAP: development done –Internal tests are successful PDP: development done –Internal tests are successful PEP: development done –Internal tests are successful gelexec/LCMAPS plug-in (--> glexec): development done –Internal tests are successful PEPd: ready by the end of this week Ongoing internal tests started one month ago Entering in certification: RSN (real soon now)

Enabling Grids for E-sciencE EGEE-III INFSO-RI Summary Development completed for all the components but one (which we’ll be ready by the end of this week) Ongoing internal tests (started one month ago) –The completed components are ready to be submitted to certification Gradual deployment in six self-contained steps –Initial focus on glexec on WN and OSCT ban list  Configuration option for glexec –Integration into CREAM and WMS for authorization –Integration into data management  Offers perspective to manage access to a site from one site-specific service –Longer term option for inclusion into match-making Feedback and volunteer sites for trying service out are highly welcome

Enabling Grids for E-sciencE EGEE-III INFSO-RI Further Information About the service: –Documentation: –AuthZ service design document: –Deployment plan: General EGEE grid security: –Authorization study: –gLite security: architecture: Other: –EGEE08 presentations:  –CHEP09 presentation: 

Enabling Grids for E-sciencE EGEE-III INFSO-RI TMB Deployment Plan (2/3) 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) 1.Grid-wide banning by OSCT OSCT offers centralized banning list to the sites

Enabling Grids for E-sciencE EGEE-III INFSO-RI Alternate Deployment Options Flexibility of the service allows different deployment models Proposal: –YAIM supports deployment on one single host –Alternate deployment options are initially supported by authZ development team on a case-by-case basis