Role Based VO Authorization Services

1. Role Based VO Authorization Services Ian Fisk Gabriele Carcassi July 20, 2005

2. Definition • Role based VO authorization: an authorization decision based on an extended credential provided by the VO server that allows a user to have different sessions in which he obtains different privileges

3. Use case • A VO compiles a list of users that can use data production resources • When acting as data production coordinator, the user gets a “token” from the VO, that states he is authorized to act in that role • The user presents that token to the site when submitting a job or initiating a file transfer • The services maps the user to a different account based on the role • The different account allows access to restricted resources or a different class of service (i.e. file access, higher queue priorities, special pool of machines, …)

4. Example: USATLAS at BNL • /atlas/usatlas/Role=production: few people (currently ~7) coordinate the data production • run under the same account ‘usatlas1’ (allows to start/stop each other jobs) • ‘usatlas1’ have a very high priority on the farm • /atlas/usatlas/Role=software: very few people (~3) that need to install remove software and debug applications • special account ‘usatlas2’, write on NFS with group readable access (rest of atlas can run applications, but not modify them) • highest priority, but on very few machines (~3) to be able to “skip” the queue (i.e. install/debug won’t wait in queue anymore) • /atlas/usatlas: all analysis users (~90) • assigned an account from the pool (i.e. grid001): allows auditing for the site • /atlas/lcg1: “international atlas” (~150) • Assigned an account from the pool with different gid (allows the batch system to differentiate between ATLAS and USATLAS to set policy accordingly) • Rest of OSG • Assigned an account from the pool, gid different for each VO • UNIX Group read/write == VO read/write

5. VOMS An example voms-proxy-init 0 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host The user, member of VO “foo”, wants to submit a job with a role “bar” to the gatekeeper of site “X”.

6. VOMS An example voms-proxy-init 1 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host The user run “voms-proxy-init –voms foo:/foo/Role=bar”, to generate his VO authorized proxy.

7. VOMS An example voms-proxy-init 2 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host Voms-proxy-init creates a normal user proxy, and then sends it to the foo VO VOMS server.

8. VOMS An example voms-proxy-init 3 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host The VOMS server returns the VOMS proxy, signed by the VO, that authorizes the user to act as “bar”.

9. VOMS An example voms-proxy-init 4 Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA grid3-user…txt gums-host The user submits the job to site X

10. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 5 grid3-user…txt gums-host The gatekeeper, through the globus call-out, delegates the PRIMA module to decide what local user account to should be used for the given GRID credential.

11. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 6 grid3-user…txt gums-host Prima extracts the Proxy information and sends a message to asks GUMS which local account should be used. (The message is a SAML authorization request)

12. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 7 grid3-user…txt gums-host GUMS consults its configuration, the local copy it keeps of the different database, and determines that the corresponding credential should be mapped to “foobar1”. GUMS returns a message, a SAML successful response with the obligation account=“foobar1”

13. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 8 grid3-user…txt gums-host PRIMA interprets the response, and return the account “foobar1” to the gatekeeper.

14. VOMS An example voms-proxy-init Submission site User VOs Execution site site GUMSServer Gatekeeper PRIMA 9 grid3-user…txt gums-host The gatekeeper sets the uid to “foobar1” and submits the job. Note: a cron jobs on the gatekeeper contact GUMS to retrieve the inverse map needed for accounting.

15. Components: VOMS • A VO service (one per VO) that provides extended proxies with signed group and role membership • Vincenzo Ciaschini, INFN - Karoly Lorentey, et al • Part of OSG 0.2.1 distribution, used in production

16. Components: PRIMA • The gatekeeper callout module that is able to contact a site Authorization service to retrieve the mapping • Markus Lorch, VT • Part of OSG 0.2.1 distribution, used in production

17. Components: GUMS • A site Authorization service that manages site-wide mappings • Gabriele Carcassi, BNL • Part of OSG 0.2.1 distribution, used in production

18. Components: VOMRS • A VO service that manages the VO Registration process, and feeds the list of currently approved members to VOMS • FNAL team • Used in production

19. Storage AuthZ Execution site Gatekeeper GRAMgridFTP site GUMSServer PRIMA SRM/dCache StorageAuthorizationService gPLAZMA

20. Components: Storage AuthZ • An authorization service that provides the extra authorization attributes required by dCache (contacts GUMS to retrieve the mapping) • Markus Lorch, VT • Prototype

21. Components: gPLAZMA • The dCache Authorization infrastructure, which is able to contact the Storage Authorization Service • Abhishek Singh Rana, UCSD et al. • Distributed as part of dCache, Beta quality, in production at Fermi in a couple of months (probably less)