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

VOMS

siteGUMSServer

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

VOMS

siteGUMSServer

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

VOMS

siteGUMSServer

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

VOMS

siteGUMSServer

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

VOMS

siteGUMSServer

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

VOMS

siteGUMSServer

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

VOMS

siteGUMSServer

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

VOMS

siteGUMSServer

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

VOMS

siteGUMSServer

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

VOMS

siteGUMSServer

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

siteGUMSServer

Gatekeeper

GRAMgridFTP

PRIMA

Execution site

SRM/dCache

gPLAZMAStorage

AuthorizationService

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)