OSG AuthZ components Dane Skow Gabriele Carcassi

Full privilege scenario User voms-proxy-init gums-host VOMS site GUMS Server Gatekeeper grid3-user…txt PRIMA centralized mapping account pool /  dynamic mappings (broken by accounting) role/group based mappings Submission site Execution site VOs

Compatibility scenario User grid-proxy-init gums-host VOMS Admin site GUMS Server gums-host Gatekeeper grid-mapfile grid3-user…txt both maps centralized mapping account pool  dynamic mappings  role/group based mappings Submission site Execution site VOs

“Ye olde Grid3” setup User grid-proxy-init Gatekeeper grid-mapfile edg-mkgridmap VOMS Admin grid3-user…txt  centralized mapping  account pool  dynamic mappings  role/group based mappings Submission site Execution site VOs

PRIMA module It’s a C library that implement the gatekeeper callout –Gets the credentials –Validates certificate and attributes –Formats a SAML message and sends it to GUMS –Parses the response –Returns the uid to the gatekeeper Distributed as part of VDT

Details PRIMA sends only the first VOMS FQAN, not the whole list encoded in the certificate. GUMS makes decisions only on one FQAN.

Attribute verification PRIMA can verify the VOMS attributes, but typically we do not do that –In OSG we lack a mechanism to easily distribute the certificates of the VO servers –GUMS verifies the presence in the VO periodically downloads the full list of users from the VO server (has to do that for maps generation) prevents forging a fake VO foresee to disable in case attribute verification is done at the gatekeeper end, and no maps are needed –Should attribute verification be delegated to the server?

PRIMA Complaints Mainly about the log –Not clear error information (the actual GUMS errors are not passed through the protocol) –Lacks a one liner entry with all information when successful (there is one, but, for example, lacks the FQAN)

What is GUMS? GUMS purpose is to manage the mapping between Grid Credentials to Site credentials –Centralized: one GUMS per site, one configuration file for all gatekeepers/services –PDP: enforcement is done at the gatekeeper/service (through grid-mapfiles or callouts) –Customizable: designed to be integrated with other site systems with little effort

Centralized management Designed by and for a site with a number of heterogeneous gatekeepers –For example, BNL GUMS has more than 10 gatekeepers (4 from STAR, 1 PHENIX, 6 ATLAS) + other ATLAS services (dCache, DIAL, …) –Some of these are OSG, some are test machines, some needs special test maps, … –One place of configuration allows control and consistency (For a small site, with one gatekeeper and 20 nodes, that is fine with a single account per VO, we currently recommend mapfiles and edg- mkgridmap.)

GUMS overview Tomcat server GUMS DB Business logic … VO … VO VOMS-Admin ldap VO Web UI (JSP) Cmd line Admin WS (Axis) Persistence (hibernate, ldap) PRIMA Web browser Glite trustmanager XML configuration AuthZ WS WS = Web Service UI = User Interface SAML + obligations over SOAP/HTTPS SOAP/HTTPS HTTPS filesystem

GUMS Policy example <userGroup className='gov.bnl.gums.LDAPGroup' server='grid-vo.nikhef.nl' query='ou=usatlas,o=atlas,dc=eu-datagrid,dc=org‘ persistanceFactory='mysql' name='usatlas' /> <userGroup className='gov.bnl.gums.VOMSGroup' url=' persistanceFactory='mysql' name='star' sslCertfile='/etc/grid-security/hostcert.pem' sslKey='/etc/grid-security/hostkey.pem'/> … …

GUMS Authorization GUMS admin can perform any operation through web service and web ui door Host can only perform read operations (map generation and mapping requests) for itself Configuration can be changed through filesystem only (automatically reloaded when changed)

GUMS performance BNL production server gives ~30 req/sec… –Not that good –Is not the bottleneck right now, as the production gatekeeper can only give ~5 req/sec Performance test show that –Overall delay (client-server-client) is ~220ms –The GUMS logic is responsible for up to 20ms –The rest is plain AXIS SOAP + SSL –It’s not glite trustmanager’s fault either…

GUMS performance JClarens group confirmed this while comparing SOAP with XML-RPC –XML-RPC without SSL: 373 req/sec – with SSL: 274 –SOAP without SSL: 218 req/sec – with SSL: 23 –10 times slower! Is it SOAP? Is it Axis implementation? At least, GUMS can run on a cluster –All state resides in the database, transactions are used, no session transfer needed, no cluster cache needed –Almost all… the configuration file is on filesystem, an needs to be updated on all machines (at the same time)

GUMS Complaints The configuration file is difficult –It usually takes people a few tries –We should simplify it –We should probably have ways to “share” parts of it (contact a location to get standard OSG groups definitions?)

Storage AuthZ (not in prod) site GUMS Server Gatekeeper GRAM gridFTP PRIMA Execution site SRM/ dCache gPLAZMA Storage Authorization Service Adds AuthZ params that are dCache specific. XACML policy. SAML + obligations over SOAP/HTTPS

Storage AuthZ gPlazma is dCache authorization infrastructure, which can be set to contact the Storage Authorization Service –Distributed as part of dCache, Beta quality The Storage AuthZ Service speaks the same SAML GUMS does, and is configured with a XACML policy –Contact GUMS to retrieve the mapping –Adds other AuthZ parameters (i.e. gid, user home path, …) –Prototype level

Other issues: maps GUMS is able to generate grid-mapfiles and also an inverse accounting map used by OSG accounting –Want to move away from them: creating a map means exploring all the policy, which breaks dynamic account mapping (i.e. for a pool, we have to assigns accounts to everybody) Assumption: we believe that inverse maps (uid-> DN) are not needed –For example, in accounting what you really need is a history of what uid was assigned to what DN. That changes with time. It’s better handled by looking at log files.

Conclusions GUMS and PRIMA are deployed in production on a number of OSG sites Privilege project depends on the following formats: –VOMS Proxy format (PRIMA) –AuthZ request: SAML + obligations (everything)