Difference: VOMSServiceReferenceCard ( vs. 1)

Revision 12012-05-18 - AndreaCeccanti

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="VOMSSystemAdministratorGuide"

VOMS Service Reference Card

1 Functional description

The Virtual Organization Membership Service (VOMS) is an attribute authority which serves as central repository for VO user authorization information, providing support for sorting users into group hierarchies, keeping track of their roles and other attributes in order to issue trusted attribute certificates and SAML assertions used in the Grid environment for authorization purposes.

VOMS is composed of two main components:

the VOMS core service, which issues attribute certificates to authenticated clients the VOMS Admin service, which is used by VO manager to administer VOs and manage user membership details.

2 Daemons running

The following daemons need to be running:

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

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

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

4 Configuration files location with example or template

The configuration files for the VOMS service are located in:

* /etc/voms/ * /etc/voms-admin/

5 Logfile locations (and management) and other useful audit information

The VOMS log files can be found under

  • /var/log/voms

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

  • /var/log/tomcat5/

6 Open ports

  • 8443 for VOMS-Admin running tomcat
  • a series of configurable ports (typically starting with the default 15000) for the voms server instances.

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

The VOMS service state is kept in the VOMS database.

8 Cron jobs

VOMS relies only on the fetch-crl cron job being active (this is configured by YAIM). There are no other VOMS specific cron jobs.

9 Security information

9.1 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.

9.2 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.

9.3 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)

9.4 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))

9.5 Security recommendations

9.6 Security incompatibilities

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

All packages are present in either EPEL or RedHat repositories

9.8 Other security relevant comments

This node-type SHOULD NOT be co-located 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.

10 Utility scripts

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

11 Location of reference documentation for users and administrators

-- AndreaCeccanti - 2012-05-18

 
TWIKI.NET
This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback