A user’s roles (Fully Qualified Attribute Names) are read from the certificate chain found within the proxy. These attributes are signed by the user’s VOMS server when the proxy is created. Starting with version 1.8, gPlazma supports checking the signature of the attributes against VOMS server certificates installed on the gPlazma node. To have gPlazma validate the proxy attributes, place the voms server certificates in /etc/grid-security/vomsdir and in /opt/d-cache/etc/dcachesrm-gplazma.policy set

The default is false. The same would need to be done on the SRM or any door node for which gPlazma modules are called directly as a fallback.

In version 1.9, VOMS attribute validation in gPlazma uses a method in which installation of the voms server certificate is not required. Instead the signature on an attribute is checked against the ca certificate that signed the voms server certificate. To have gPlazma validate the proxy attributes in dCache 1.9, write configuration directories and "*.lsc" files in /etc/grid-security/vomsdir for each authorized voms server according to these instructions and in /opt/d-cache/etc/dcachesrm-gplazma.policy set

As with previous versions, the default is false. Whether validation is on or not, there must be a non-empty /etc/grid-security/vomsdir on the node which is running gPlazma. It is enough to do

[root] # mkdir /etc/grid-security/vomsdir
touch /etc/grid-security/vomsdir/empty-cert.pem

to create the non-empty directory.

In dCache version 1.7, SRM or the GridFTP door delegated the user’s credentials to gPlazma, and the user’s attributes were extracted from the secure context. For performance purposes, starting in version 1.8 the delegation step is not performed. To turn on delegation, in /opt/d-cache/config/dCacheSetup on the node running SRM or the GridFTP door, set the line

The default value is false. To support delegation, host certificates must exist on the host which runs gPlazma.