GUMS status

1. GUMS status Gabriele Carcassi PPDG Common Project 12/9/2004

2. Outline • GUMS description • Status • Issues encountered during development and other open issues

3. What is GUMS? • GUMS allows a site to centrally manage the mapping between Grid Identity to local identity according to a site wide policy /DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi Grid resource BNL GUMS carcassi <xmlPolicy> On *.usatlas.bnl.gov allow: Members of Grid3 VO mapped with accounts taked from a pool Members of a special list from a database mapped to ‘special’… </xmlPolicy>

4. Features planned for OSG-0 • Account pooling • Service implementation • Role based authorization

5. Account Pooling • A generic grid user will be assigned a generic grid account (no recycling) from a pool of pre-created accounts -> This affects applications and accounting … /DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi grid0009 /DC=org/DC=doegrids/OU=People/CN=Dantong Yu grid0010 grid0011 /DC=org/DC=doegrids/OU=People/CN=Razvan Popescu grid0012 grid0013 /DC=org/DC=doegrids/OU=People/CN=Dantong Yu grid0014 grid0015 • Will allow BNL cybersecurity to perform auditing • To go in production we need: • Assign the group id after the assignment • Make sure it doesn’t disrupt accountingand applications grid0016 grid0017 …

6. GUMS service • Use gatekeeper call-out to contact GUMS directly Grid resource … VO PHENIX VO STAR VO ATLASVO Grid resource Grid resource GUMS server A client on the gatekeeper can contact GUMS to retrieve the grid-mapfile or other maps. No role-based authentication in that case. GUMS DB

7. Role based authorization • Use of callout and of VOMS extended proxy /DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi Grid resource BNL GUMS carcassi /DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi /VO=ATLAS/Group=USATLAS/Role=production-leader Grid resource BNL GUMS usatlasprod

8. Components • Gatekeeper call-out implementation (C client) – Markus Lorch, Privilege Project • GUMS GT3 service that implements callout protocol – Java implementation over GT3 • GUMS service (WebService and UI interface for admin commands) – Separate Java web application, no GT3 • GUMS Admin – Command line client for WebService door (Java) • GUMS Host client – Command line client to retrieve host maps (Java)

9. Components Web Browser GUMSService GUMSServer Contact VO serverand refresh user lists GUMSAdmin GRIDResource GUMS GT3 Retrieve mapfor this host GUMSclient Map this user GKCallout

10. Status • GUMS components are essentially complete. Just needs consolidation. • Account pooling: at BNL we have a grid3dev gatekeeper implementing account pools managed by GUMS (through grid-mapfile) since the end of August. It’s suitable to test accounting and applications. No tests have been yet performed so far. • Role based authentication working on the testbed. • User retrieves VOMS extended proxy • Submits job to gatekeeper • Gatekeeper call-out contacts GUMS • GUMS returns local user (according to policy) • Problems in using GT3 security within the C client (gatekeeper call-out) – not a major issue as we can always use plain web services • Implementation for storage callout hasn’t started yet

11. Security • We performed a set of tests to compare GT3 message level security and EGEE (glite) transport level security (plain WS) • req/sec was 17 times better with transport level security • For the GUMS Admin Web Services interface, we are using plain SOAP (Axis) with glite transport level security. • The Web UI also uses glite transport level security (web interfaces can’t be used with message level security). • The interface for the call-out is still targeted to GT3 with message level security, but: problems in C client. • What are other people doing?

12. Logs • Not using GT3 logging: not flexible enough • Hides the Log4j implementation, and doesn’t allow to use Syslogd or Mail appenders to forward logs by mail or to syslogd • Not usable for Web UI, which doesn’t use GT3 • Different logs for different audience • Developer log: used for debugging, logs internals of the code. • GUMS admin log: logs activity at the functionality level. Complete log is saved to a file, error level entries are sent through mail to the admin. • CyberSecurity log: logs access (read at different level than writes), uses syslogd to integrate with facility logging. • For example, if ATLAS VOMS returns no members for a group set in GUMS configuration, no problem at the developer level, but very likely a problem at the admin level.

13. Experience with GT3 • Performance problems in message level security • Had to eliminate logging implementation • Difficult to integrate: • Configuration files are bundled in libraries, multiple axis libraries when accessing web services • Build-process from the tutorial is suitable only for the tutorial (no other examples) • Spreads files in various tomcat directories (probable legacy from httpg)

14. Clustering • We are investigating clustering to provide high availability with GUMS. • Tomcat 5 includes a load balancer. • We are also investigating fail-over mechanisms. • Still in investigation phase.

15. Other issues • Packaging for OSG • How should the service be packaged? Which type of package, PACMAN? • Interaction with accounting service