For VOMS 2.0.16, VOMS Admin server 3.8.1, VOMS Admin client 2.0.21
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 following daemons need to be running:
For the voms service
service voms start
service voms status
service voms stop
For the voms-admin service
service voms-admin start
service voms-admin status
service voms-admin stop
For the voms service, SystemD instantiated services are used. This means that a voms service instance needs to be started for each deployed VO:
systemctl start voms@vo
systemctl status voms@vo
systemctl stop voms@vo
# To restart all instances
systemctl restart voms@'*'
For the voms-admin service:
systemctl start voms-admin
systemctl stop voms-admin
systemctl status voms-admin
This command starts and stop the voms-admin container.
The deployment of individual VOs is controlled using the
voms-vo-ctl utility.
The configuration files are located in:
/etc/voms//etc/voms-admin/The log files can be found under
/var/log/voms/var/log/voms-adminThe following ports need to be open depending on the services running:
voms: one for each vo, tipically 1500xvoms-admin: one, tipycally 8443The VOMS service state is kept in the VOMS database. Location and access information for the database can be found in the configuration files.
VOMS relies only on the fetch-crl cron job being active. There are no other VOMS specific cron jobs.
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.
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.
Three services are running that need network access on this node-type.
voms-admin server which binds at one tcp port (typically 8443/tcp)voms server which binds to one tcp port per VO (usually something like 15010/tcp)See Open ports.
None.
None.
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.