Some newer requirements (e.g., reverse mapping, banning) could not be
integrated into gPlazma1 without making major changes on its
architecture. Since the effort would have only beed slightly less than a
reimplementation, we decided to keep the established gPlazma1 and
create a new version from scratch that could offer modern features for
those who already require them. In the long term gPlazma2 is meant
to replace gPlazma1 completely. For this reason it supports most
of the latter’s authentication methods. But not only offers
gPlazma2 new features, it also comes with flexible architecture
that can be extended by plug-ins. Since many authentication methods
share some functionality (e.g., use storage-authdb)
the same functionality that was covered by one plug-in in version 1 is
now divided into several plug-ins. This way, if for example you used
the gplazmalite-vorole-mapping plug-in of gPlazma1 you will now need to use
the vorolemap plug-in and the authzdb plug-in to get the same functionality.
Currently gPlazma2 comes with seven plug-ins that can be used to
cover a wide range of systems. Check if yours is among those. Some
plug-ins are designed for backwards compatibility and will work with your
existing files (e.g., vorolemap) and some offer
completely new functionality (e.g., NIS/LDAP mapping, ARGUS
banning).
gPlazma2 has several advantages over gPlazma1 in means of
design, flexibility and functionality. Its behaviour is easily
configurable with a PAM-style configuration file, that will be described in
detail in the next section.
To use gPlazma2, the first thing you have to do is to activate
it by setting gplazma.version to
2 in dcache.conf. This is
described in the first part of this chapter. Afterwards edit
/etc/dcache/gplazma.conf with your
favourite editor (e.g., vim) to match your requirements. The plug-ins
will be used in the order auth, map, account and session.
Within these groups they are used in the order they are specified.
It 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
Each line consists of one of the keywords auth, map, account,
session or identity followed by one of the modifiers optional,
required, requisite or sufficient, the name of the
plug-in and a list of parameters. Empty lines and lines starting with a
# are comments and will be ignored. With the first
keyword you specify the type of the plugin (some plug-ins implement
several types) and the modifier defines how success or failure of the
plugin is handled. The configured plugins are then combined into two
stacks. The first is processed each time a authentication decision has
to be made and the second stack is used to perform mapping and reverse
mapping. The first stack consists of auth, map, account and
session plugins, the second one only of identity plugins.
auth|map|account|session|identity optional|required|requisite|sufficient <plug-in> ["<key>=<value>" ...]
authauth-plug-ins are used to read the users public and private credentials and ask some authority, if those are valid for accessing the system.mapmap-plug-ins map the user information obtained in theauthstep to UID and GIDs. This may also be done in several steps (e.g., thevorolemapplug-in maps the users DN+FQAN to a username which is then mapped to UID/GIDs by theauthzdbplug-in.accountaccount-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.sessionsessionplug-ins usually enrich the session with additional attributes like the user’s home directory.identityidentityplug-ins have have two functions to map from usernames to UID and GID and vice versa.
The meaning of the modifiers follow the PAM specification:
optionalThe success or failure of this plug-in is only important if it is the only plug-in in the stack associated with this type.
sufficientSuccess 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
gPlazma2immediately proceeds with the next plug-in type or returns control to the door if this was the last stack.requiredFailure of such a plug-in will ultimately lead to
gPlazma2returning failure but only after the remaining plug-ins for this type have been invoked.requisiteLike
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 four different types of plug-ins. These types
correspond to the keywords auth, map, account, session and identity
from the previous section.
The authzdb plug-in implementation offers map and session
functionality. As a map-plug-in it takes a username and maps it
to UID/GID using the storage-authzdb file.
| Parameter | Meaning | Default |
|---|---|---|
authzdb | Path to storage-autzdb | /etc/grid-security/storage-authzdb |
The argus plug-in is an account plug-in, currently used for banning
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.
| Parameter | Meaning | Default |
|---|---|---|
HostCert | Path to host certificate | /etc/grid-security/hostcert.pem |
HostKey | Path to host key | /etc/grid-security/hostkey.pem |
KeyPass | Password for host key | |
TrustMaterial | Path to CA certificates | /etc/grid-security/certificates |
PEPEndpoint | URL of PEP service | https://localhost:8154/authz |
The gridmap plug-in is a mapping plug-in. It maps GLOBUS identities
and Kerberos identities to a username.
| Parameter | Meaning | Default |
|---|---|---|
gridmap | Path to grid-mapfile | /etc/grid-security/grid-mapfile |
The kpwd plug-in has auth, map and session capabilities. It
authorizes users by username and password, by pairs of DN and
FQAN and by Kerberos principals. 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.
| Parameter | Meaning | Default |
|---|---|---|
pwdfile | Path to dcache.kpwd | /etc/dcache/dcache.kpwd |
The voms plug-in is a auth plug-in. It can be used to verify X.509
certificates. It takes the certifcates and checkes 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.
| Parameter | Meaning | Default |
|---|---|---|
cadir | Path to ca certificates | /etc/grid-security/certificates |
vomsdir | Path to vomsdir | /etc/grid-security/vomsdir |
The voms plug-in is a map plug-in. It can be used to map pairs
of DN and FQAN to a username via a vorolemap
file.
| Parameter | Meaning | Default |
|---|---|---|
vorolemap | Path to grid-vorolemap | /etc/grid-security/grid-vorolemap |
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.