VOMS Service Reference Card

Functional description

VOMS is a system to classify users that are part of a Virtual Organization (VO) on the base of a set of attributes that will be granted to them upon request and to include that information inside Globus-compatible proxy certificates.

VOMS consists of two main components:

• VOMS - includes the VOMS server and the VOMS client tools and APIs (e.g. voms-proxy-init)
• VOMS Admin - a Web application used to manage users and their privileges for a VO

Released version

Official VOMS stable version: 2.0 Official VOMS Admin stable version: 2.6.1

Daemons running

The following daemons need to be running:

• tomcat5
• vomsd
• mysql (in case of MySQL is running directly on the VOMS server)

Init scripts and options (start|stop|restart|...)

• /etc/init.d/voms (start|stop|restart)
• /etc/init.d/voms-admin (start|stop|restart)

Configuration files location with example or template

The configuration files for the VOMS service are located in:

• /etc/voms/

Logfile locations (and management) and other useful audit information

VOMS core

The VOMS log files can be found under

• /var/log/voms

VOMS Admin

The VOMS Admin logfiles can be found, together with other tomcat log files, in

• /var/log/tomcat5/

Open ports

Open ports are 8443 for voms-admin and a series of configurable ports (typically starting with the default 15000) for the voms server instances.

Possible unit test of the service

voms comes with a testsuite that can be run through ETICS

Where is service state held (and can it be rebuilt)

There is no significant service state associated with VOMS. voms-admin only has state when a registration request is being processed, and such state is kept in the DB.

Cron jobs

The cron jobs can be found in:

• /etc/cron.d/

and are:

• /cron.d/glite-fetch-crl.cron
• /cron.d/ccm-purge.cron
• /cron.d/ccm-fetch.cron

Security information

Access control Mechanism description (authentication & authorization)

This node type has two interfaces. One for the administration where VO admins can add/remove users and assign VO Roles and a second one where the middleware applications ask for proxy signature. On both interfaces the authentication part is done via x509 authentication against the trusted CAs that are installed at the node. The authorization part is done via the VO roles that are assigned to the uses's DN.

How to block/ban a user

It is possible to fine tune access rules to the VOMS administrator services using Access Control Lists. See the VOMS Admin user's guide for more information on this. Note that however it is safe to leave read access on to any authenticated client, as this functionality it is still used to create gridmap files for some middleware components. The access to the proxy signature interface is limited to the users that are listed as active members to the VO. Removing a user from the VO, or suspending his membership, will block his/her ability to obtain a valid proxy signature from the VOMS server. See the VOMS Admin user's guide for more information on how to remove and suspend users in a VO.

Network Usage

Three services are running that need network access on this node-type.

• the MySQL server service. The server binds to the 3306/tcp port. Alternatively, Oracle may be used, which is usually run on a different node. Access to this node should be allowed.
• the VOMS-Admin webapp on a TomCat server at the 8443/tcp port.
• the vomsd server which binds to one tcp port per VO (usually something like 15010/tcp)

Firewall configuration

The proposed firewall configuration is to deny access to anyhost/anyport and allow:

• 8443/tcp from everywhere (this is used for VO management (via x509 authentication) and gridmapfile creation)
• Any vomsd server configured port (i.e. 15010/tcp) from everywhere (this is used by users directly (from UIs or WNs) or indirectly (from WMSes))
• Any other administration required port for the administration subnet/interface (i.e. 22/tcp (ssh))

Security recommendations

Security incompatibilities

List of externals (packages are NOT maintained by Red Hat)

All packages are present in either EPEL or RedHat repositories

Other security relevant comments

This node-type should not be collocated with any other node-type and should not allow shell access to users. Any connection other than the ones described above should be treated as suspicious.

Utility scripts

• voms-admin (client & server side)
• voms-proxy-* (client side)
• voms-db-deploy.py (server side)
• voms-admin-configure (server side)

Location of reference documentation for users

• Official EMI VOMS documentation
• VOMS FAQ for service managers
• Another VO management FAQ

Location of reference documentation for administrators

See user documentation.

-- VincenzoCiaschini - 13-Apr-2011