gPlazma2
is configured by the PAM-style configuration file
/etc/dcache/gplazma.conf
.
Each line of the file is either a comment (i.e., starts with #
,
is empty, or defines a plugin. Plugin defining lines start with the
plugin stack type (one of auth
, map
, account
, session
identity
),
followed by a PAM-style modifier (one of optional
, sufficient
,
required
, requisite
), the plugin name and an optional list of
key-value pairs of parameters. During the login process they will be executed
in the order auth
, map
, account
and session
. The identity
plugins
are not used during login, but later on to map from UID+GID back to user
names (e.g., for NFS). Within these groups they are used in the order they
are specified.
auth|map|account|session|identity optional|required|requisite|sufficient <plug-in> ["<key>=<value>" ...]
A complete configuration file will look something like this:
Example:
# Some comment auth optional x509 auth optional voms map requisite vorolemap map requisite authzdb authzdb=/etc/grid-security/authzdb session requisite authzdb
Login Phases
auth
auth
-plug-ins are used to read the users public and private credentials and ask some authority, if those are valid for accessing the system.map
map
-plug-ins map the user information obtained in theauth
step to UID and GIDs. This may also be done in several steps (e.g., thevorolemap
plug-in maps the users DN+FQAN to a username which is then mapped to UID/GIDs by theauthzdb
plug-in.account
account
-plug-ins verify the validity of a possibly mapped identity of the user and may reject the login depending on information gathered within the map step.session
session
plug-ins usually enrich the session with additional attributes like the user’s home directory.identity
identity
plug-ins are responsible for mapping UID and GID to user names and vice versa during the work with dCache.
The meaning of the modifiers follow the PAM specification:
Modifiers
optional
The success or failure of this plug-in is only important if it is the only plug-in in the stack associated with this type.
sufficient
Success of such a plug-in is enough to satisfy the authentication requirements of the stack of plug-ins (if a prior required plug-in has failed the success of this one is ignored). A failure of this plug-in is not deemed as fatal for the login attempt. If the plug-in succeeds
gPlazma2
immediately proceeds with the next plug-in type or returns control to the door if this was the last stack.required
Failure of such a plug-in will ultimately lead to
gPlazma2
returning failure but only after the remaining plug-ins for this type have been invoked.requisite
Like
required
, however, in the case that such a plug-in returns a failure, control is directly returned to the door.
gPlazma2
functionality is configured by combining different types
of plug-ins to work together in a way that matches your requirements.
For this purpose there are five different types of plug-ins. These types
correspond to the keywords auth
, map
, account
, session
and
identity
as described in the previous section. The plug-ins can be
configured via properties that may be set in
dcache.conf
, the layout-file or in
gplazma.conf
.
The kpwd
plug-in authorizes users by username and password, by pairs
of DN and FQAN and by Kerberos
principals.
Properties
gplazma.kpwd.file
Path to
dcache.kpwd
Default:
/etc/dcache/dcache.kpwd
The voms
plug-in is an auth
plug-in. It can be used to verify X.509
credentials. It takes the certificates and checks their validity
by testing them against the trusted CAs. The verified certificates
are then stored and passed on to the other plug-ins in the stack.
Properties
gplazma.vomsdir.ca
Path to ca certificates
Default:
/etc/grid-security/certificates
gplazma.vomsdir.dir
Path to
vomsdir
Default:
/etc/grid-security/vomsdir
The X.509
plug-in is a auth
plug-in that extracts X.509
certificate chains from the credentials of a user to be used by
other plug-ins.
As a map
plug-in it maps usernames to UID and GID. And as a
session
plug-in it adds root and home path information to the
session based on the user’s username.
Properties
gplazma.kpwd.file
Path to
dcache.kpwd
Default:
/etc/dcache/dcache.kpwd
The authzdb
plug-in takes a username and maps it to UID+GID using
the storage-authzdb
file.
Properties
gplazma.authzdb.file
Path to
storage-authzdb
Default:
/etc/grid-security/storage-authzdb
The gridmap
plug-in maps GLOBUS identities and Kerberos
identities
to usernames.
Properties
gplazma.gridmap.file
Path to
grid-mapfile
Default:
/etc/grid-security/grid-mapfile
The voms
plug-in maps pairs of DN and FQAN to usernames via a
vorolemap
file.
Properties
gplazma.vorolemap.file
Path to
grid-vorolemap
/etc/grid-security/grid-vorolemap
The krb5
plug-in maps a kerberos principal to a username by removing
the domain part from the principal.
Example:
user@KRB-DOMAIN.EXAMPLE.ORG
to user
The nsswitch
plug-in uses the system’s nsswitch
configuration to provide mapping.
Typically nsswitch
plug-in will be combined with vorolemap
plug-in,
gridmap
plug-in or krb5
plug-in:
Example:
# Map grid users to local accounts auth optional x509 #1 auth optional voms #2 map requisite vorolemap #3 map requisite nsswitch #4 session requisite nsswitch #5
In this example following is happening: extract user’s DN (1), extract and verify VOMS attributes (2), map DN+Role to a local account (3), extract uid and gids for a local account (4) and, finally, extract users home directory (5).
The nis
plug-in uses an existing NIS
service to map username+password
to a username.
Properties
gplazma.nis.server
NIS
server hostDefault:
nisserv.domain.com
gplazma.nis.domain
NIS
domainDefault:
domain.com
The result of nis
plug-in can be used by other plug-ins:
Example:
# Map grid or kerberos users to local accounts auth optional x509 #1 auth optional voms #2 map requisite vorolemap #3 map optional krb5 #4 map optional nis #5 session requisite nis #6
In this example two access methods are considered: grid based and
kerberos based. If user comes with grid certificate and VOMS role:
extract user’s DN (1), extract and verify VOMS attributes (2),
map DN+Role to a local account (3). If user comes with Kerberos
ticket: extract local account (4). After this point in both cases
we talk to NIS
to get uid and gids for a local account (5) and,
finally, adding users home directory (6).
The argus
plug-in bans users by their DN. It talks to your site’s
ARGUS system (see
https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework
) to check for banned users.
Properties
gplazma.argus.hostcert
Path to host certificate
Default:
/etc/grid-security/hostcert.pem
gplazma.argus.hostkey
Path to host key
Default:
/etc/grid-security/hostkey.pem
gplazma.argus.hostkey.password
Password for host key
Default:
gplazma.argus.ca
Path to CA certificates
Default:
/etc/grid-security/certificates
gplazma.argus.endpoint
URL of PEP service
Default:
https://localhost:8154/authz
The kpwd
plug-in adds root and home path information to the session,
based on the username.
Properties
gplazma.kpwd.file
Path to
dcache.kpwd
Default:
/etc/dcache/dcache.kpwd
The authzdb
plug-in adds root and home path information to the session,
based and username using the storage-authzdb
file.
Properties
gplazma.authzdb.file
Path to
storage-authzdb
Default:
/etc/grid-security/storage-authzdb
The nsswitch
plug-in adds root and home path information to the
session, based on the username using your system’s
nsswitch
service.
Typically nsswitch
plug-in will be combined with vorolemap
plug-in,
gridmap
plug-in or krb5
plug-in:
Example:
# Map grid users to local accounts auth optional x509 #1 auth optional voms #2 map requisite vorolemap #3 map requisite nsswitch #4 session requisite nsswitch #5
In this example following is happening: extract user’s DN (1), extract and verify VOMS attributes (2), map DN+Role to a local account (3), extract uid and gids for a local account (4) and, finally, extract users home directory (5).
The nis
plug-in adds root and home path information to the session,
based on the username using your site’s NIS
service.
Properties
gplazma.nis.server
NIS
server hostDefault:
nisserv.domain.com
gplazma.nis.domain
NIS
domainDefault:
domain.com
The result of nis
plug-in can be used by other plug-ins:
Example:
# Map grid or kerberos users to local accounts auth optional x509 #1 auth optional voms #2 map requisite vorolemap #3 map optional krb5 #4 map optional nis #5 session requisite nis #6
In this example two access methods are considered: grid based and
kerberos based. If user comes with grid certificate and VOMS role:
extract user’s DN (1), extract and verify VOMS attributes (2),
map DN+Role to a local account (3). If user comes with Kerberos
ticket: extract local account (4). After this point in both cases
we talk to NIS
to get uid and gids for a local account (5) and,
finally, adding users home directory (6).
The nsswitch
plug-in provides forward and reverse mapping for NFSv4.1
using your system’s nsswitch
service.
The nis
plug-in forward and reverse mapping for NFSv4.1
using your
site’s NIS
service.
Properties
gplazma.nis.server
NIS
server hostDefault:
nisserv.domain.com
gplazma.nis.domain
NIS
domainDefault:
domain.com
Even though gPlazma1
comes as plug-ins for gPlazma2
it
has a special role and it’s plug-ins should not be mixed with other
plugins. To use gPlazma1
set gplazma.conf
to
auth requisite gplazma1 map requisite gplazma1 session requisite gplazma1
The gPlazma1
can be called from the
, the
GridFTP
door
, and the dCap
doorsrm
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
, see the section called “Configuration files”.
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.
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
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
”.
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.
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.
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.
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 UID and GID are
obtained via the
storage-authzdb
file.
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.