Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
VOMS Service Reference Card
1 Functional descriptionThe 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 runningThe following daemons need to be running:
3 Init scripts and options (start|stop|restart|...)
4 Configuration files location with example or templateThe configuration files for the VOMS service are located in: * /etc/voms/ * /etc/voms-admin/5 Logfile locations (and management) and other useful audit informationThe VOMS log files can be found under
6 Open ports
7 Where is service state held (and can it be rebuilt)The VOMS service state is kept in the VOMS database.8 Cron jobsVOMS relies only on thefetch-crl cron job being active (this is configured by YAIM). There are no other VOMS specific cron jobs.
9 Security information9.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 userIt 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 UsageThree services are running that need network access on this node-type.
9.4 Firewall configurationThe proposed firewall configuration is to deny access to anyhost/anyport and allow:
9.5 Security recommendations9.6 Security incompatibilities9.7 List of externals (packages are NOT maintained by Red Hat)All packages are present in either EPEL or RedHat repositories9.8 Other security relevant commentsThis 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
11 Location of reference documentation for users and administrators-- AndreaCeccanti - 2012-05-18 |