1. USATLAS deployment We currently use VOMS Role based authorization in production within USATLAS. In the VO we have defined 4 groups/roles that satisfy our current needs (and that are a large improvement from the past). We need to distinguish between –/atlas/usatlas/Role=production: few people (currently ~7) that coordinate the data production –/atlas/usatlas/Role=software: very few people (~3) that need to install remove software and debug applications; in grid3 these operation where always slow as they had to wait for the job to run: we want to give them almost real-time response –/atlas/usatlas: USATLAS users (~90) –/atlas/lcg1: rest of ATLAS (~150) Where are those group defined?

2. VO servers dependencies Arrows signify dependencies (not dataflow) VOMS (Admin+Server) vo.racf.bnl.gov LDAP VO grid-vo.nikhef.nl OSG edg-voms-ldap-sync All groups and roles are defined in the ldap VO server as ldap groups. A cron script running every night synchronizes the BNL VOMS server with the ldap VO server. OSG (and USATLAS) users depend from the VOMS server installed at BNL. What about migration to CERN VOMS/VOMRS? OSG dependencies USATLAS dependencies

3. Planned migration Arrows signify dependencies (not dataflow) VOMS (Admin+Server) vo.racf.bnl.gov LDAP VO grid-vo.nikhef.nl OSG edg-voms-ldap-sync VOMS (Admin+Server) voms.cern.ch VOMS (Admin+Server) lcg-voms.cern.ch VORMS lcg-voms.cern.ch bnl-atlas-sync During migration, CERN is going to provide 2 VOMS servers (one with the old lists and one with the new). BNL is going to combine info in the prod server. Configuration for the ldap synch at BNL for ATLAS is exactly the same as the CERN one.

4. After migration Arrows signify dependencies (not dataflow) OSG VOMS (Admin+Server) lcg-voms.cern.ch VORMS lcg-voms.cern.ch Once all users are migrated, the production server for OSG will become the VOMS server at CERN. USATLAS groups and roles are planned to be present in the final CERN VOMS server as they are defined now in the BNL VOMS server. Migrating to BNL to CERN must be transparent to the users (i.e. just change the VO server name in the configuration files, and change certificates where needed)

5. Role implementation at BNL ATLAS VO lcg1 usatlas production software usatlas1 (usatlas) usatlas2 (usatlas) gridxxxx (gridgr07, usatlas) gridxxxx (gridgr07) BNL accounts Rest of OSG: gridxxxx (gridgrxx) All users are mapped to an account from the pool, with the gid set to the VO group. The 2 USATLAS roles are mapped to 2 special accounts. The batch system can now distinguish between different sets just by looking at the uid and gid. File permissions can be set to have read/write access within VOs. Production and software roles allow read/write access within the group.

6. At other USATLAS sites They are free to choose what implementation is best for them as long as they can distinguish between groups and implement ATLAS/USATLAS policies accordingly Two methods USATLAS supports are: –As BNL (2 special accounts + pool) –Simpler for smaller sites who do not have tight security requirements (4 accounts) Some sites will probably implement in their ad- hoc way, integrated with their user management system.