VOMS Support for Castor SRM2

This page describes and defines the support for proxy certificates with VOMS extensions in CASTOR SRM, as they are being collected from and agreed with Experiments' representatives and other parties. Savannah BUG:64377 tracks development activities related to this topic.

Definitions

• VOMS extensions or FQANs (Fully Qualified Attribute Names): attributes attached to a grid proxy certificate. Include:
  • VO, e.g. dteam.
  • Sub-group, e.g. dteam/cern.
  • Role, e.g. lcgadmin. NULL is a valid role.
  • Capability; this attribute is deprecated.

Background information

CASTOR authorization mechanisms are based upon (local) uids/gids, both at the namespace level, by means of ACLs, and at the request processing level, by means of so-called black and white lists in the stagers. Because of this, CASTOR SRM shall provide a mapping mechanism from VOMS Roles to uids/gids.

Current gridmap-file-based mechanism shall be preserved for backwards compatibility when the user's certificate is a plain grid certificate.

Proposed implementation

• A VOMS Role is to be mapped to a uid: CASTOR does not support multiple (secondary) gids, and the namespace already contains entries where different uids have been used to distinguish roles and authorizations, hence a Role-to-uid mapping seems preferable instead of a Role-to-gid mapping.

• A new mapping file will need to be provided, with a format similar to the grid-mapfile. This file could be stored as /etc/grid-security/voms-mapfile and needs to be (quattor-)managed by operations teams. E.g.:

     "/dteam/cern/Role=lcgadmin" lcgadmin
     "/dteam/Role=lcgadmin" lcgadmin
     "/atlas/Role=pilot" atlas003
     "/atlas/Role=NULL" atlas001

• If the certificate passes the authentication phase, VOMS extensions are assumed to be valid. In other words, only one of the following three scenarios is foreseen:
  1. The user presents an invalid (e.g. expired) certificate. The user is refused access to the SE.
  2. The user presents a valid plain grid proxy certificate. Current grid-mapfile-based mapping is applied.
  3. The user presents a valid VOMS proxy certificate with at least a Role. The new mapping scheme is applied.
• SRM will pick up only the Role attribute and its group/sub-group from the VOMS extensions, and match it with the existing mapping rules:
  • Groups and sub-groups are considered different entities, and different rules must exist to cover all sub-groups in order to have a match.
  • Rules are applied in order until the first match is found. Multiple matches are considered configuration errors and ignored.
• In case no match is found because the voms-mapfile has no entry for the given Role, the VOMS extensions are ignored and SRM falls back to the grid-mapfile.

Technical details

• The first part of /etc/castor/srm2_storagemap.conf provides static mapping from usernames to VOs. This is still in use for plain certificates, while it is ignored for VOMS certificates as the VO name is fetched from the certificate.

-- GiuseppeLoPresti - 08-Mar-2011