The Virtual
Organisation Membership Service is a front-end to an RDBMS,
where all
the information about users is kept. It allows the administrator to register
members within a VO (members should provide
their DN, CA and Group affiliation).
During the grid job submission a member issues voms-proxy-init (instead
of
grid-proxy-init) and gets extended proxy from the VOMS server.
This proxy certificate includes the member's Groups and Roles as
additional attributes. Some issues that
are not satisfactory in LDAP today are handled by VOMS as follows:
Last Update: 2004-11-10The notes appended date from October 2003 but
they are not obsolete.
For those readers who want to deploy a service, here are some useful
references to related documentation:
What is VOMS:
Why should VOMS replace today's LDAP-based VO management:
This is solved in VOMS via a user-friendly web interface. The database
used in VOMS today is MySQL.
This is solved in VOMS by using the
entire DN coupled with the responsible CA name.
This is solved
in VOMS by keeping a separate instance for every VO database.
This is
solved in VOMS by using LCAS/LCMAPS instead
of gridmap. It is alreadly available today on the Computing Element (CE)
of the LCG testbed. It is possible to use LCAS/LCMAPS without VOMS, with,
obviously, reduced functionality.
The configuration for the VOMS daemon is in the directory /opt/edg/etc/voms .
The actual data are in /var/lib/mysql/voms_[VOname].
The configuration for the edg-voms-admin service is kept in the directory /opt/edg/var/etc/edg-voms-admin. We
may agree, in the near future, to locate all these configurations in the
same directory.
The "Trusted CA list" is picked up and regularly updated with
a cron job from the /etc/grid-security/certficates directory of
the VOMS server.
The web interface looks
like: https://tbed0152.cern.ch:8443/edg-voms-admin/[VO-name]/index.html .
It can only be opened by VO managers, whose certificates are included in
the VOMS configuration by its administrator.
The configuration
file of the VOMS web interface is in /opt/edg/etc/voms-httpd/httpd.conf .
The user interface is lxshare0276.cern.ch (the LCG-2 UI host). Users registered
on that host can issue the edg-voms-proxy-init command. Example:
Your identity: /O=Grid/O=CERN/OU=cern.ch/CN=Maria Dimou
Enter GRID pass phrase for this identity:
Creating proxy .......................................... Done
/C=CH/O=CERN/OU=GRID/CN=host/tbed0152.cern.ch
/C=CH/O=CERN/OU=GRID/CN=CERN CA
....................................
Next step (when implemented) would be to change the "ldap://" entries
in
the
gridmap config.
file by "voms://" entries (phase
1 migration scenario).
Present administration issues:
Items 1 and 2 below are submitted with Bugzilla on 2003-10-28 (http://marianne.in2p3.fr/datagrid/bugzilla/show_bug.cgi?id=2178)
The remaining problem is how to manage grid users (who may belong to many VOMS
Groups) and files on the computing resources (
VOMS is installed and
tested in Fermilab. There will be further tests during the GRID3 run.
Related applications:
SAZ (Site Authorisation Service) : FNAL site access control commissioned
by the Security Team in order to quickly respond to
any security incident and
block
user
access
to the site regardless
of user's standing in the VO. So, any job submitted from outside (e.g.
via gatekeeper) will first access the SAZ database to check the user status
at the site. This is done
by using gatekeeper's
callouts. This is a mechanism that allows to access
extensions of authorisation (not covered in the limited set of Globus) offered
by other applications.
LRAS (Local Resource Authorisation Service) : fine grain control
to local resource and mapping to user account. This is done by using gatekeeper
callout to access a local database where a VO member is mapped to a Unix account,
and the local administrator can ban / allow member's access to the local resource.
The FNAL team plans to use the VOMS core server to generate extended proxy, and probably the VOMS admin package to populate the VOMS database. So they will probably keep two separate databases: one with members dn,ca and groups and another with all the registration information.
BNL (input from R.Baker):
GUMS is a tool, developed in the US, that automatically maintains a static one-to-one mapping between Distinguished Name (DN) and local account name.
The static one-to-one account mapping has several advantages. One major consideration
is that many
sites (both in the US and Europe) have serious reservations about allowing
group or pool account
mapping. The static mapping simplifies site audit procedures. It also solves
the file protection issues.
GUMS and VOMS are very complimentary. The current deployments of GUMS are
using VOMS servers
to obtain the list of users. GUMS produces a different grid-mapfile and logs
account mapping information
locally. GUMS can use VOMS group membership info to maintain a local user account's
membership in
local Unix groups.
GUMS could also allow account recycling, so the problem of total number
of available UIDs (limited to 64K on some systems today) can be handled if
it does become a limit for the Grid. Alternatively, operating
systems should increase the length of the UID from 16 to 32 bits.
Differences/similarities in these approaches:
SAZ and LRAS contain overlapping functionality with each other and with LCAS/LCMAPS to the extent that they can be considered similar but one can't make a one-to-one mapping between these products. As they all followed completely different implementation paths SAZ and LRAS use RDBMS to store user and group information, wherelse LCAS/LCMAPS use flat files (that may contain regular expressions to ease mass-updating).
chih-chiang.chang@cern.ch, maria.dimou@cern.ch (installation, evaluation)
Tanya Le
Rich Baker <rbaker@BNL.GOV> (GUMS contact)
project-lcg-deployment-staff@cern.ch (advice and use)
project-lcg-security-group@cern.ch (advice)
