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

gPlazma2

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.

[return to top]

Configuration

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 /opt/d-cache/etc/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>" ...]

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 the auth step to UID and GIDs. This may also be done in several steps (e.g., the vorolemap plug-in maps the users DN+FQAN to a username which is then mapped to UID/GIDs by the authzdb 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 have have two functions to map from usernames to UID and GID and vice versa.

The meaning of the modifiers follow the PAM specification:

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.

[return to top]

plug-ins

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.

[return to top]

authzdb

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.

ParameterMeaningDefault
authzdbPath 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.

ParameterMeaningDefault
HostCertPath to host certificate/etc/grid-security/hostcert.pem
HostKeyPath to host key/etc/grid-security/hostkey.pem
KeyPassPassword for host key 
TrustMaterialPath to CA certificates/etc/grid-security/certificates
PEPEndpointURL of PEP servicehttps://localhost:8154/authz

[return to top]

GridMap

The gridmap plug-in is a mapping plug-in. It maps GLOBUS identities and Kerberos identities to a username.

ParameterMeaningDefault
gridmapPath 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.

ParameterMeaningDefault
pwdfilePath to dcache.kpwd/opt/d-cache/etc/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.

ParameterMeaningDefault
cadirPath to ca certificates/etc/grid-security/certificates
vomsdirPath to vomsdir/etc/grid-security/vomsdir

[return to top]

vorolemap

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.

ParameterMeaningDefault
vorolemapPath to grid-vorolemap/etc/grid-security/grid-vorolemap

[return to top]

X.509 plug-in

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.