90 likes | 209 Views
VOMS Architecture. WP4 (EDT) Meeting Bologna, October 8 2002. available soon!. VOMS components. Client contacts the server presenting user certificate and obtains a list of groups, roles and capabilities of the user voms-proxy-init command Server
E N D
VOMS Architecture WP4 (EDT) Meeting Bologna, October 8 2002
available soon! VOMS components • Client • contacts the server presenting user certificate and obtains a list of groups, roles and capabilities of the user • voms-proxy-init command • Server • receives requests from clients and returns information about the user • Secure communications client-server • Current implementation in C, MySQL • Administration interface • Permits creation and management of users, groups, roles, capabilities • implementation in Java (Tomcat) • implementation in php (https) WP4 (EDT) Meeting
Authentication Request OK Query AuthDB VOMSpseudo-cert VOMSpseudo-cert VOMS user VOMS Operations • Mutual authentication Client-Server • Secure communication channel via standard Globus API • Client sends request to Server • Server checks correctness of request • Server sends back the required info (signed by itself) in a “Pseudo-Certificate” • Client checks the validity of the info received • Client repeats process for other VOMS’s • Client creates proxy certificates containing all the info received into a (non critical) extension C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy WP4 (EDT) Meeting
capabilities cid dn membership user group role capability groups users gid uid dn dn aclid ca acl … aclid principal operation allow/deny VOMS DB Structure CA caid dn roles rid dn WP4 (EDT) Meeting
Client Command Options • All the queries have an implicit <userid> field, derived from the certificate presented by the user to the server. • A: all info regarding the user • G <group>: info regarding the user as a member of the specified group • R <role>: info regarding the specified role • C <capability>: info regarding the specified cabability • B<group>:<role>: info regarding the user as member of specified group with the specified role • L lists all available queries in table referenced by the S option • S <qid> executes the SQL operation <qid> WP4 (EDT) Meeting
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 a “true” Authorization Certificate (RSN) /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 server identity TIME1: 020710134823Z TIME2: 020711134822Z GROUP: montecarlo ROLE: administrator 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... WP4 (EDT) Meeting
Intermezzo: mkgridmap++ • Coexistence of VOMS and VO LDAP servers • mkgridmap++ • produces grid-mapfiles from both LDAP and VOMS servers; • new config file directive • voms:// • authenticated access to VOMS (not LDAP) servers • temporary change to VOMS authentication mechanism (?) WP4 (EDT) Meeting
LCAS • Handles authorization requests to local fabric • Modifications needed for gatekeeper • Dynamic library calls from edg-gatekeeper • Authorization decisions based on proxy user certificate and job specification • Supports gridmapfile mechanism • 3 authorization modules • Allowed users (grid-mapfile or allowed_users.db) • Banned users (ban_users.db) • Available timeslots (timeslots.db) • Plug-in framework (hooks for external authorization plug-ins) • e.g. from Storage Element to check file access or quota WP4 (EDT) Meeting
EDG gatekeeper EDG1.3 EDG1.4, EDG2.x Gatekeeper Gatekeeper LCAS config TLS auth TLS auth Id ACL timeslot Yes/no LCAS (so) LCAS client gridmap LCMAPS clnt Id LCMAPS assist_gridmap config apply creds * credlist Jobmgr-* Jobmgr-* role2uid role2afs * And store in job repository by Martijn Steenbakkers (EDG WP4)