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/Roleproduction 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/Rolesoftware 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 wont 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
An example

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

voms-proxy-init
1
Submission site
User
VOs
Execution site
site GUMSServer
Gatekeeper
PRIMA
grid3-usertxt
gums-host
The user run voms-proxy-init voms
foo/foo/Rolebar, to generate his VO authorized
proxy.
7
An example

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

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

voms-proxy-init
4
Submission site
User
VOs
Execution site
site GUMSServer
Gatekeeper
PRIMA
grid3-usertxt
gums-host
The user submits the job to site X
10
An example

voms-proxy-init
Submission site
User
VOs
Execution site
site GUMSServer
Gatekeeper
PRIMA
5
grid3-usertxt
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
An example

voms-proxy-init
Submission site
User
VOs
Execution site
site GUMSServer
Gatekeeper
PRIMA
6
grid3-usertxt
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
An example

voms-proxy-init
Submission site
User
VOs
Execution site
site GUMSServer
Gatekeeper
PRIMA
7
grid3-usertxt
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 accountfoobar1
13
An example

voms-proxy-init
Submission site
User
VOs
Execution site
site GUMSServer
Gatekeeper
PRIMA
8
grid3-usertxt
gums-host
PRIMA interprets the response, and return the
account foobar1 to the gatekeeper.
14
An example

voms-proxy-init
Submission site
User
VOs
Execution site
site GUMSServer
Gatekeeper
PRIMA
9
grid3-usertxt
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)