# Presentation: 473311

## Role Based VO Authorization Services

- Ian Fisk
- Gabriele Carcassi
- July 20, 2005

## 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

## 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, ...)

## 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

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 0

- The user, member of VO “foo”, wants to submit a job with a role “bar” to the gatekeeper of site “X”.

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 1

- The user run “voms-proxy-init –voms foo:/foo/Role=bar”, to generate his VO authorized proxy.

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 2

- Voms-proxy-init creates a normal user proxy, and then sends it to the foo VO VOMS server.

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 3

- The VOMS server returns the VOMS proxy, signed by the VO, that authorizes the user to act as “bar”.

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 4

- The user submits the job to site X

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 5

- 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.

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 6

- 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)

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 7

- 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”

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 8

- PRIMA interprets the response, and return the account “foobar1” to the gatekeeper.

## An example

- User

- voms-proxy-init

- gums-host

- site
- GUMSServer

- Gatekeeper

- grid3-user...txt

- PRIMA

- Submission site

- Execution site

- VOs

- 9

- 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.

## 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

## 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

## Components: GUMS

- A site Authorization service that manages site-wide mappings
- Gabriele Carcassi, BNL
- Part of OSG 0.2.1 distribution, used in production

## 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

## Storage AuthZ

- site
- GUMSServer

- Gatekeeper
- GRAMgridFTP

- PRIMA

- Execution site

- SRM/dCache

- gPLAZMA

- StorageAuthorizationService

## 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

## 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)