1 / 13

VOMS etc

VOMS etc. Andrew McNab University of Manchester. Outline. “Credential soup” X.509/GSI VOMS Shibboleth OpenID, XYZ, ??? Summary. “Credential Soup”. “Grid projects typically generate one new acronym for every 10,000 lines of code” (McNab's Law of Grid Acronyms?)

mikkel
Download Presentation

VOMS etc

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. VOMS etc Andrew McNab University of Manchester

  2. Outline • “Credential soup” • X.509/GSI • VOMS • Shibboleth • OpenID, XYZ, ??? • Summary

  3. “Credential Soup” • “Grid projects typically generate one new acronym for every 10,000 lines of code” • (McNab's Law of Grid Acronyms?) • Grid Security is no exception: • X.509, GSI, CAS, LDAP-VO, GACL, VOMS, XACML, SAML, Shibboleth, VOM, WS-Sec, ... • This talk is a quick review of credentials relevant to LCG/EGEE and how GridPP is involved.

  4. X.509 / GSI • The first part of GridPP to go into production (before GridPP started!) was the Certification Authority at RAL • Issues the X.509 user and host certificates that we use • Globus's GSI defined the proxies that running jobs have • Eventually became RFC3820 and “Respectable” • gLite workload system uses GridPP's GridSite Delegation Protocol to give GSI proxies to jobs • Between X.509 and GSI, the authentication problem was “Solved” pretty much from the start

  5. VOMS • VOMS was developed to address authorization • “X.509 Attribute Certificates” (AC) • ie a digitally signed statement that a user belongs to one or more groups • Users fetch a VOMS AC with voms-proxy-init • AC included in proxy that authenticates user to sites • AC proves membership of one or more groups • Users can also request proof of roles within groups

  6. VOMS implementations • INFN CNAF/Bologna • VOMS AC issuing server: the only server implementation in production and derived from Globus gatekeeper • VOMS parser for C/C++: again, depends of Globus libs • CERN/KTH (“EDG WP2”) • Java Security: now part of gLite, and used by gLite Java • GridPP VOMS implementations • GridSite for C/C++/scripts: used by Apache based gLite Web Services (eg WM Proxy) • Java AC creator/parser (“Acacia”) from Imperial

  7. VOMS certificates • Original version of VOMS required that the host certificate of each VOMS server was installed on each machine wanting to verify VOMS credentials • Not at all scalable, especially if VOMS server certificates are renewed each year • VOMS now has the option to require only the DN of the host certificate to be stored on each verifying machine • ie uses the digital signatures to verify authority

  8. VO naming • EDG/EGEE/LCG documents have been produced saying that VO names should be DNS names • (this was originally a GridPP idea from EDG) • eg expX.cern.ch not just expX • guarantees uniqueness (eg US vs official VOs) • DNS uniqueness allows for dynamic/lightweight VOs • Most of the middleware will accept DNS VO names • Some outstanding problems identified by GridPP with deployment scripts

  9. Policy Languages • Many subsystems within LCG/EGEE use some form of access control policies • Either internally managed lists of authorised users/managers for that service • Or ACLs (POSIX-like ACLs?) • Or full blown policy languages • GridPP has provided GACL which is used by the workload management system at sites • Also support XACML standard, but this unused...

  10. Shibboleth • Shibboleth was endorsed by JISC as a replacement for ATHENS at UK universities • Part of Internet2 in the US, and developed for controlling access to campus facilities (journal subscriptions etc) • Shibboleth allows websites (“service providers”) to redirect users to their home website (“identity providers”) to authenticate • Passes the success of this in the background with SAML (attribute assertions in XML) messages • As part of the JISC-funded FAME project, we have added Shibboleth support to GridSite

  11. Shibboleth + GridPP • www.gridpp.ac.uk now uses GridSite 1.4.x which includes Shibboleth support • GridSite identity provider also includes an interface to VOMS • The Shibboleth protocol is sufficiently flexible to allow us to disclose VOMS attributes to websites • User's register with X.509 certificate and choose username / password • However, while there is only a single Service Provider www.gridpp.ac.uk and a single Identity Provider, this could be achieved with a PHP script on a single webserver...

  12. OpenID etc • New security technologies continue to emerge that may become relevant to GridPP • especially to portals and other “web-like” components • eg OpenID is gaining momentum in the “blogosphere” • basically a simplified reimplementation of Shibboleth • concentrates on authentication without attributes • Inexorable WS-* processes grind on producing standards which again, may nor may not become relevant to LCG/EGEE

  13. Summary • Authentication technology was “solved” at the start • Requires ongoing operations effort of course • Delegation re-implement for gLite Web Services • VOMS provides proof of VO/Group membership • GridSite is used to access VOMS credentials from C/C++/Scripts based services • Several access policy systems (ACLs, GACL, ...) • JISC, EGEE, ... have expressed support for Shibboleth • But new acronyms generated every 10k lines or so!

More Related