1 / 18

Grid Security for Site Authorization in EDG VOMS, Java Security and LCMAPS

Grid Security for Site Authorization in EDG VOMS, Java Security and LCMAPS. David Groep, NIKHEF davidg@nikhef.nl EDG Security Coordination A. Frohner – CERN D. Kouril -   CESNET F. Bonnassieux - CNRS R. Alfieri, R. Cecchini, V. Ciaschini, L. dell'Agnello, A. Gianoli , F. Spataro - INFN

bgay
Download Presentation

Grid Security for Site Authorization in EDG VOMS, Java Security and LCMAPS

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. Grid Security forSite Authorization in EDGVOMS, Java Security and LCMAPS David Groep, NIKHEFdavidg@nikhef.nl EDG Security Coordination A. Frohner – CERN D. Kouril -   CESNET F. Bonnassieux - CNRS R. Alfieri, R. Cecchini, V. Ciaschini, L. dell'Agnello, A. Gianoli , F. Spataro - INFN O. Mulmo – KDC D.L. Groep, M. Steenbakkers, W. Som de Cerff, O. Koeroo, G. Venekamp – NIKHEF L. Cornwall, D. Kelsey, J. Jensen – RAL A. McNab – University of Manchester P. Broadfoot, G. Lowe – University of Oxford http://hep-project-grid-scg.web.cern.ch/

  2. Talk Outline • Introduction • Authorization requirements • VO Membership Service • Java Security for Hosted Environments • Native Mechanisms (LCAS, LCMAPS) • Conclusions  

  3. Authentication – only the first step • EDG security infrastructure based on X.509 certificates (PKI) • Authentication • Needs “trusted third parties”: 16 national certification authorities • Policies and procedures  mutual thrust • Users identified with “identity” certificates signed by a national CA See also next talk by Dave Kelsey… • Authorization • Several entities involved • Resource Providers (e.g. computer centres, storage providers, NRENs) • Virtual Organizations (e.g. LHC experiments collaborations) • Cannot decide Authorization for grid users only on local site basis

  4. high frequency low frequency CA CA CA User’s Authorization in Globus host cert(long life) service user crl update user cert(long life) grid-proxy-init proxy cert(short life) grid-mapfile authentication info

  5. high frequency low frequency CA CA CA User’s Authorization in EDG 1.4.x host cert(long life) service user crl update user cert(long life) VO-LDAP registration VO-LDAP grid-proxy-init VO-LDAP mkgridmap proxy cert(short life) grid-mapfile VO-LDAP authentication info

  6. VOMS Overview • Provides info about the user’s relationship with his VO(’s) • groups, “compulsory” groups, roles (admin, student, ...), capabilities (free form string), temporal bounds • Features • single login:voms-proxy-init only at the beginning of the session (replaces grid-proxy-init); • expiration time: the authorization information is only valid for a limited period of time (possibly different from the proxy certificate itself); • backward compatibility: the extra VO related information is in the user’s proxy certificate, which can be still used with non VOMS-aware services; • multiple VO’s: the user may authenticate himself with multiple VO’s and create an aggregate proxy certificate; • security: all client-server communications are secured and authenticated.

  7. high frequency low frequency CA CA CA registration service cert(short life) authz cert(short life) User’s Authorization in EDG 2.x host cert(long life) service user crl update user cert(long life) VO-VOMS registration VO-VOMS voms-proxy-init VO-VOMS proxy cert(short life) VO-VOMS authz cert(short life) authentication & authorization info edg-java-security LCASLCMAPS

  8. Pseudo-Certificate Format • The pseudo-cert is inserted in a non-critical extension of the user’s proxy • 1.3.6.1.4.1.8005.100.100.1 • It will become an Attribute Certificate • One for each VOMS Server contacted /C=IT/O=INFN/L=CNAF/CN=Vincenzo Ciaschini/Email=Vincenzo.Ciaschini@cnaf.infn.it/C= IT/O=INFN/CN=INFN CA user’s identity /C=IT/O=INFN/OU=gatekeeper/L=PR /CN=gridce.pr.infn.it/Email=alfieri@pr.infn.it /C=IT/O=INFN/CN=INFN CA VO: CMS URI: http://vomscms.cern.ch server identity TIME1: 020710134823Z TIME2: 020711134822Z GROUP: montecarlo ROLE: administrator CAP: “100 GB disk” user’s info SIGNATURE: .........L...B]....3H.......=".h.r...;C'..S......o.g.=.n8S'x..\..A~.t5....90'Q.V.I..../.Z*V*{.e.RP.....X.r.......qEbb...A...

  9. Tomcat & java-sec Perl CLI axis VOMSimpl Web interface servlet Apache & mod_ssl voms-httpd VOMS Architecture vomsd GSI voms-proxy-init soap + SSL DB JDBC https DBI mkgridmap https MySQLdb – with history and audit records • User query server and client (C++) • Java Web Service based administration interface • Perl client (batch processing) • Web browser client (generic administrative tasks) • Web server interface for mkgridmap VOMS server

  10. dn User VOMS dn + attrs service authenticate service Java C authr LCAS pre-proc pre-proc ACL ACL map authr LCMAPS LCAS Coarse-grainede.g. Spitfire Fine-grainede.g. RepMeC Coarse-grainede.g. CE, Gatekeeper Fine-grainede.g. SE, /grid Authorization

  11. Authorization for Web Services • Java TrustManager can secure both web sites and web services • Based on Apache Tomcat Catalina servlet container • SOAP client, as an extension of the Axis SocketFactoryFactory • HTTP client, as an API that creates HTTPS connections. • Authorization Mngr gives attributes based on userDN and VOMS extensions • For web services • Service uses proxy of host • For browser interaction • Must use long-lived host certto be TLS compliant

  12. Services secured by EDG-Java-Sec • Spitfireuniform access to SQL database services (MySQL, DB/2, Oracle) • Replica Location Service, RepMeC, Giggle – metadata and replica information services • VOMS server • R-GMARelational Grid Monitoring Architecture – Information System • Basis for new OGSA/WebServices components

  13. Authorization for Native Environments • All systems for running Grid jobs and storing files are UNIX based • Need for interface between Grid rights and local rights • Two-phase process • Authorization of users: LCAS • Acquiring and enforcing local (UNIX-style) credentials: LCMAPS • Why the split? • Authorization decisions may be applied for more than single resources • Credential mapping may be time-consuming and “heavy” • Internal service securitycredential mapping needs root privileges, authorization can do without

  14. C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy VOMSpseudo-cert LCAS Service LCAS: Local Centre AuthZ Service • Authorization using: • Authentication + VO data • Job description • Site policy exec=/bin/catarguments=/etc/passwd GateKeeper GridFTPServer • Plug-in frameworkcurrently shipping modules • Allowed-users list • Banned-users list • wall-clock limitations GateKeeper Job Manager Node Node Node Node Node Node Node Node Node other clusters

  15. accept GSI AuthN LCAS authZ call out • LCMAPS open, learn,&run: • … and return legacy uid C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy VOMSpseudo-cert Job Manager fork+exec args, submit script LCMAPS – Local Credential MAPping • Provides local credentials needed for jobs within the fabric • Plug-in framework, driven by (site specific)policy • Mapping based • user identity • VO affiliation, groups and roles • site-local policy • Supports multiple credential types: • Traditional POSIX: in-process & LDAP, via fixed or PoolAccounts* • AFS tokens • true Kerberos5

  16. LCMAPS – new functionality • Local UNIX groups based on VOMS group membership and roles • More than one VO and group/role per grid user • No pre-allocation of pool accounts to specific groups • New mechanisms: • groups-on-demand • support for central user directories (primarily LDAP) • Why do we continue to need LCAS? • Centralized site decisions on authorized users for multiple fabrics • Coordinated access control across multiple CEs and SEs • (and save on ‘expensive’ account allocation mechanisms in LCMAPS)

  17. Conclusions • EDG provides extensive Grid authorization infrastructure today • LCAS* and Java-security already deployed • VOMS and LCMAPS ready for deployment (confirmed for June ’03) • Updates for various services in October ’03 User Side • Support for large, fast-changing user community • Roles and groups within the experiment VOs • Multiple affiliations and roles per user Resource Side • Minimal effort on resource provider side • More smooth integration in Grid computing at large • Retains tracability and auditability at all levels

  18. More Information EDG Security Coordination Group Web site http://hep-project-grid-scg.web.cern.ch/ VOMS Web site http://grid-auth.infn.it/ CVS site http://cvs.infn.it/cgi-bin/cvsweb.cgi/Auth/ Developers’ mailing listsec-grid@infn.it PoolAccounts Web site http://www.gridpp.ac.uk/authz/gridmapdir/ LCAS-LCMAPS Web site http://www.dutchgrid.nl/DataGrid/wp4/ CVS site http://datagrid.in2p3.fr/cgi-bin/cvsweb.cgi/fabric_mgt/gridification/lcas/ http://datagrid.in2p3.fr/cgi-bin/cvsweb.cgi/fabric_mgt/gridification/lcmaps/ Maillist hep-proj-grid-fabric-gridify@cern.ch EDG Java Security Web site http://edg-wp2.web.cern.ch/edg-wp2/security/

More Related