AGD Grid Account Management

1
AGD Grid Account Management
2
AGD Grid Account Management

• VO Management in running projects
• EGEE gLite
• Open Science Grid (OSG) VO Privilege
• VOMRS Features
• Using VOMRS with GT4
• Pragmatic solution volist merge-gridmap
• manage-local-gridaccounts Flowchart
• Serving multiple VOs Sub-VOs

3
VOMS/VOMRS in EGEE gLite

VOMRS
(Igor Sfiligoi gLite Authentication)
4
VOMS/VOMRS in OSG
VOMRS
Grid Facility
register
CE
Globus Gatekeeper
SRM
JobManager
SE
membership/ privileges
get proxy
callouts
callouts
get uid, gid, rootpath
gPlazma
PRIMA
membership/ privileges
Is authorized?
SAZ
VOMS
Facility Authorization Management
get uid
GUMS
submit job
(Tanya Levshina VOMRS)
5
AGD Grid Account Management

• VOMRS VO Management,
• volist communication
• manage-local-gridaccounts local process

NFS homes
accounts homes
Grid resource
group name
manage- local -grid-accounts
VOMRS DB
local grid- mapfile
volist servlet
local config
List (DNID) more
(cronjob)
grid- mapfile
Auth lists
Site-RA
manage
User
VOMRS
Globus Gatekeeper
Submit job
register
JobManager
6
VOMRS Features

• secure authenticated management of VO
  membership, grid resource authorization and
  privileges
• 2-phase registration workflow to register users
  with a VO
• Dynamic set of collected personal information
• Management of multiple grid certificates per
  member
• VO-level control of member's privileges
• Email notifications of selected changes and
  events
• Permits delegation of responsibilities within the
  various VO administrators and group managers
• Manages hierarchies of groups and group roles
• Interfaces to third-party systems like VOMS

7
volist

• Features
• interfacing VOMRS database via jndi
• extracting required information via
  sql-statements
• multiple options for data retrieval
• SELECT CONCAT('"',a.distinguished_name,'"') AS
  dn, a.member_id-1 AS id
• FROM member_dns a, members b
• WHERE a.is_primary_ind'Y' AND
  a.member_idb.member_id AND
• b.member_status'Approved'
• implemented as webapplication for tomcat
  container
• http queries (htpasswd-security)
• https queries (htpasswd-security certification
  based authentication of host)
• wget --http-user Kerr --http-passwd Einstein \
  "http//mintaka.aip.de8080/volist/vomembers?print
  _id1"

8
Manage local grid accounts
wget/https
RunAs aliases

Create sudoers entries
volist/ VOMRS
use visudo
VO list
Command entries
Local policies
Map to pool account schema
Write grid-mapfile
grid- mapfile
Keep copy
Prefixformat agd .3d
Create account for new DN
Log new accounts
Remove non-allowed DNs
Allowed DNs
Log unknown accounts
Check account existence
Remove denied DNs
Denied DNs
Remap with local gridmap
local grid- mapfile
Higher priority
Remap DNs to non-pool accounts
Remap DNID
9
ManageLocalGridAccounts.pl

• Features
• Queries list of VOMRS servers via volist for
  generating actual list of VO members
• parses listing into an adaptable schema of
  locally configurable usernames and groups
  (accounts)
• creates accounts on demand with checking
  existence and home
• allows for nfs-homes in cluster environments
  (separates creation of accounts and homes, if
  required)
• addition create_remote_homes.pl takes local
  list from the script and creates via ssh (or rsh)
  homes, accounts and gridmap on nfs-host
• creates new gridmap file
• is designed to run as a regular cron job
• takes a list of VORMS-servers and option lists
  for different VO

10
Serving multiple (Sub-)VOs
local grid- mapfile

VOMRS DB
Grid resource
volist servlet A
manage-gridmap
Config Sub-VO /Omega/Uno
VOMRS A
Config VO /Alpha
manage-gridmap
VOMRS DB
Auth lists
volist servlet ?
manage-gridmap
Config VO /Omega
VOMRS ?
grid- mapfile
11
Differences to GUMS

• GUMS
• duplicates VO-Management locally
• by creating locally another VO-management tool
• requires manual administration of local accounts
• is a "site tool" as opposed to a "VO tool
• implements (weak) interaction with gatekeepers
• substitutes the gridmap file
• requires local (java) coding for group/account
  mappings
• does not generate accounts on demand
• does not have a clean separation of
  VO-Management, information retrieval and local
  resource policies
• requires additionally PRIMA on local resources
• requires additional exchange mechanism for
  information exchange VOMRS UNICORE
• already has a clean implementation against OGSA
  AuthZ Interface (callout)

12
Summary

• Using volistManageLocalGridUser.pl with VOMRS
• separation into three independent steps
• managing VOs with VORMS
• user registration
• local RA manages membership for their users
• central VO managers manage VO membership
• retrieval of information from VORMS
• volist queries and retrieval of different sets
  of information
• for resource-providers
• other middleware UNICORE
• VOMS VOMRS exchange
• local grid-account management with
• ManageLocalGridUser.pl with
• different mapping schema and choices
• one-to-one mapping

13
D-Grid Development

• Thinking ahead
• Currently
• HEP uses VOMS
• All other CG use Globus they need VOMRS
• UNICORE will remain a special thing for HPC, but
  UUDB has to be served as well
• All need a regular (and flexible) means to manage
  their VO
• Since VOMRS is independent of underlying
  middleware, we should use this on the
  VO-Management level
• Since almost every CG uses Globus, a solution for
  VO Management has to be based on this fact
• VOMS is heavily relying on gLite, so its a
  non-option for all CG except HEP
• D-Grid Call II
• new CG are waiting to be integrated into D-Grid
• they will base their grid infrastructure on
  Globus

14
D-Grid Development

• Thinking ahead
• very few CG, except HEP and AGD, have a
  VO-Management established
• Core D-Grid registers 30..40 users
• But if only this amount of users comes from each
  CG, which hopefully will be the situation within
  the next year, a centralized approach will become
  unmanageable or inefficient (aka users with
  certificates waiting on end to be registred on
  local resources, which already now is a common
  experience).
• Consequence establishing a
• CG-centered VO-level management now with a VOMRS
  for each CG
• interchange of data between those servers on a
  regular basis
• separating VO-Management and local user
  management
• linking both with simple tools
• will be an absolute necessity now
• Inefficient VO-Management is one of the main
  obstacles for getting users interested in grid
  infrastructure and thus for the transformation
  from a playing ground for informatic freaks into
  a production means for science