release notes | Book: 1.9.5, 1.9.12 (opt, FHS), 2.11 (FHS), 2.12 (FHS), 2.13 (FHS), 2.14 (FHS), | Wiki | Q&A black_bg
Web: Multi-page, Single page | PDF: A4-size, Letter-size | eBook: epub black_bg

gPlazma1

gPlazma1 comes with support for five different authentication and mapping methods. Each method is implemented in a plug-in-like module.

[return to top]

Configuration

The gPlazma cell can be called from the GridFTP door and the dCap door and the srm server.

This section describes how to configure gPlazma1 in general. You also need to adjust the plug-in specific configuration files, depending on which authorization methods you choose to employ. The configuration of the plug-ins is described later in this chapter, since the files are also used by gPlazma2.

The gPlazma policy, located in the /etc/dcache/dcachesrm-gplazma.policy file, controls the authorization plug-ins to be used (ON or OFF for each plug-in) and the order of their execution.

Example:

# Switches
xacml-vo-mapping="OFF"
saml-vo-mapping="ON"
kpwd="ON"
grid-mapfile="OFF"
gplazmalite-vorole-mapping="OFF" 

The order of execution is specified by assigning a different number to each plug-in, such as

# Priorities
xacml-vo-mapping-priority="5"
saml-vo-mapping-priority="1"
kpwd-priority="3"
grid-mapfile-priority="4"
gplazmalite-vorole-mapping-priority="2" 

In the above example, only the saml-vo-mapping plug-in and the kpwd plug-in are activated (i.e., switched ON). Of those the saml-vo-mapping plug-in would be tried first, because it was assigned a higher priority. Note that the higher the value the lower is the plugins priority. If authorization was denied for that method, or if the authentication method itself failed, then the next activated plugin with the next lower priority would be tried. In this example this would be the kpwd plug-in. If the gplazmalite-vorole-mapping plug-in would also be activated, it would be tried after the saml-vo-mapping plug-in and before the kpwd plug-in.

Activating more than one plug-in allows plug-ins to be used as fall-back for another plug-ins that may fail. It also allows for the authorization of special users who may be denied by the other methods.

After the general configuration the policy file also contains a section for each of the plug-ins with plug-in specific configuration. These sections are described in the documentation for each plug-in, as follows. You may delete or comment out the lines specifing the priorities and configuration for unused plug-ins.

Here is an example of how a policy file might be set up.

Example:

# Switches
xacml-vo-mapping="OFF"
saml-vo-mapping="ON"
kpwd="ON"
grid-mapfile="OFF"
gplazmalite-vorole-mapping="OFF"

# Priorities
saml-vo-mapping-priority="1"
kpwd-priority="3"

# dcache.kpwd
kpwdPath="/etc/dcache/dcache.kpwd"

# SAML-based grid VO role mapping
mappingServiceUrl="https://fledgling09.fnal.gov:8443/gums/services/GUMSAuthorizationServicePort"
saml-vo-mapping-cache-lifetime="60"

In this case, gPlazma1 will attempt to authorize first through a GUMS server, and fall back to using dcache.kpwd. The mappingServiceUrl would have to be changed to a GUMS server appropriate for the site.

[return to top]

Configuring VOMS Attribute Validation

VOMS attribute validation in gPlazma1 does not require VOMS server certificates. Instead the signature of an attribute is checked against the CA Certificate that signed the VOMS server certificate. To have gPlazma1 validate the proxy attributes in dCache, write configuration directories and *.lsc files in /etc/grid-security/vomsdir for each authorized VOMS server according to these instructions and set the vomsValidation in /etc/dcache/dcachesrm-gplazma.policy to true.

Note

The legacy method of using *.pem files which contain the VOMS server certificates is still supported. To achieve this add the *.pem file which contains the certificate of the VOMS server to the directory /etc/grid-security/vomsdir/.

Note that it is recommended to use the *.lsc files for the VOMS attribute validation as with this method you don’t need to keep the VOMS server certificate up to date.

The default is to validate the attributes. In both cases there must be a non-empty /etc/grid-security/vomsdir directory on the node which is running gPlazma1. To create a working dummy directory it is enough to do

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

[return to top]

plug-ins

This section describes the five different authentication methods for gPlazma1. Four of them share the common file storage-authzdb for mapping usernames to UID/GID and provide additional user specific path information. The format of this file is described in the section called “storage-authzdb.

[return to top]

gplazmalite-vorole-mapping plug-in

The gplazmalite-vorole-mapping plug-in maps a combination of DN and FQAN (Fully Qualified Attribute Name) to a username using a vorolemap file. The subsequent mappings to UID and GID is done via the storage-authzdb file.

[return to top]

kpwd plug-in

The kpwd plug-in uses a kpwd file for authorization and mapping. This is the legacy method and is recommended only for testing and/or rather small and independent sites or as a fallback method. The file contains different records for authorization and mappings. Its format is documented within the sample file in /usr/share/dcache/examples/gplazma/dcache.kpwd. In the first step a DN or Kerberos principal is mapped to a username. To authorize the user has to provide the password belonging to the mapped username to get UID and GID and user path information.

[return to top]

grid-mapfile plug-in

This plug-in uses a grid-mapfile to map DNs to usernames. The subsequent mapping to UID/GID is done via the storage-authzdb file.

[return to top]

saml-vo-mapping plug-in

This plug-in requests DN to username mappings from a GUMS server (Grid User Management System). The GUMS service may run an extension which returns the UID/GID plus the additional user path information. Without this extension UIDand GID are obtained via the storage-authzdb file.

[return to top]

xacml-vo-mapping plug-in

This plug-in requests DN to username mappings from a GUMS server with XACML support. The GUMS service may run an extension which returns the UID/GID plus the additional user path information. Without this extension UID and GID are obtained via the storage-authzdb (see the section called “storage-authzdb) file.