Last modified 11 years ago Last modified on 05/14/10 21:59:17


This document contains gPlazma functionality proposal and a clarification of terms. It reflects views of one developer, it is an input for the dCache Workshop and does not reflect actual agreements achieved during the workshop.

This document describes the gPlazma plugin mechanism and how abstract plugins may interact to achieve the process of (in some cases) authenticating users, identifying users and course-grain authorisation of users.

The authentication is qualified because some doors may have already authenticated the user as part of the process of establishing a network connection (e.g., SSL, GSI, Kerberos). In other cases, the user may present a username-password pair to authenticate themselves and gPlazma will authenticate the user.

Identifying the user is solely the responsibility of gPlazma [NB this may be a small lie for doors that support user NOBODY; but we may choose to ask gPlazma anyway]. dCache components currently uses different principal-types to make authorisation decisions, so the process of establishing the user's identity involves establishing these principal types.

Course-grain authorisation is where users may be wholesale prevented from accessing dCache in any fashion, for any operation. This is sometimes called "black listing". If the user is not allowed to use dCache then the the door should reject the user (usually in some protocol-specific fashion) and not forward Messages to any other dCache component on behalf of that user.


This document uses some terms that may be misunderstood. To reduce potential confusion, a brief set of definitions are given here

Term Definition
The process of establishing a user's (external) identity. Examples include:
  • checking username-password against database,
  • in SSL, obtaining client certificate and verifying the chain-of-trust.
credentials the data used in the authentication process
public credentials non-secretive credential; e.g., public key, username.
private credentials some secret information; e.g., password.
principal generalisation of the concept of a "name", a representation of some entity; e.g., DN, username, UID, kerberos principal. A principal may have meaning within dCache generally whereas credentials are only used to establish principals
identification The process of mapping credentials to principals.
course-grain authorisation Whether the user is allowed to use dCache at all. It could be that the user is banned. If so, we wish to prevent any use of dCache.
account metadata information about the user independent of their principals or credentials; e.g., home directory, (namespace) root directory.
logging in the process of authentication, identification, checking course-grain authentication and establishing account metadata.


The Pluggable Authentication Modules (PAM) system for allowing users to "log in" with various identity-granting software (login, kdm, gdm, sudo, cups, passwd, xscreensaver, ...). It has a history of some 15 years of use.

PAM identifies four activities ("type"s) that it is involved with. These are listed below with a brief description.

this is "course-grain authorisation" (using above nomeclature). It controls whether a user is allowed to log in based on non-credential factors. For example, allowing a user to log-in only during working hours, ensuring that root is allowed to log in from the console only, enforcing a maximum number of concurrent log-ins for a group of users.
this is both authentication and identification. Examples for authentication are support for username+password, username + kerberos, ssh; examples for identification are NIS/nsswitch, LDAP.
This allows a user to update how they identify themselves: allowing a user to change their password (typ. one password module for each auth module).
establishing the users session; e.g., logging information, mounting directories, etc.

The session PAM type is about establishing the context for the user within the system. For dCache, this involves establishing the account metadata associated with the user (home directory, root directory), recording that the user is logged in, etc. We may choose to establish the session ID for the user as part of this process.

The account PAM type is course-grain authorisation. This type allows the banning of a user: either directly or based on an external service.

The auth PAM type is the process of authentication and identification. In PAM, this type also includes the challenge-response needed to gather credentials. In dCache, this process takes place in the door, so we exclude this process from gPlazma.

The password PAM type is interesting; supporting this would allow end-users to change their password within dCache. However, since we don't support this just now, it's deliberately left off the scope of this document.

Phases in gPlazma log-in

We identify five phases for logging into dCache. Each phase has a well-defined goal, which is part of the overall process of logging the user into dCache. The names are deliberately similar to those of PAM.

In general, each of the five phases are processed in turn. Processing a phase involves interacting with one or more plugins. Plugins are not necessarily involve with all phases: some plugins may be used only in one phase, others may be responsible for several phases, yet others could be involved in all phases.

There are several phases where a user's login attempt will be denied by a plugin. If that happens then subsequent phases are not undertaken.

The five phases are presented here in the order they are processed.

the process of checking user-supplied credentials are valid
the process of identifying group-membership
the process of identifying the user as an individual
the process of allowing or denying the user to log in
establishing the user's session; including account metadata and logging activity

These are discussed below in more detail.

Relationship with PAM

The gPlazma phases account and session correspond directly to the PAM types account and session respectively.

The authentication, id-group and id-user phases correspond roughly to the auth type in PAM. There are some differences, though:

o the PAM auth type includes the possibility of a challenge-response (e.g. prompting a user for a password). In gPlazma, this is (currently) not possible. o there are three phases (authentication, id-group and id-user) which is to simply configuration.

authentication phase

This is the first phase when a user logs in. This phase checks that the user-supplied credentials are valid; for example, if the user supplies username and password credentials this phase is responsible for checking that the password is correct for that user.

For kerberos and GSI/TLS/SSL-based authentication, the door currently verifies that the credential is valid. gPlazma can trust that the door has authenticated the user correctly and, if a Kerberos or SSL credential is supplied then authorise the user.

If the user supplies defective credentials (e.g., a wrong password) then the user may be denied access at this point.

After the authentication phase, the id-group phrase it undertaken.

id-group phase

The id-group phase identifies which groups the user is a member of that can be identified independently of how their unique identity is mapped.

Here are some example mechanisms where an X509 certificate may result in activity in id-group phase:

  1. if the certificate has a VOMS extension, extract the FQANs and add an FQAN and GID Principal for each FQAN.
  2. if the certificate has no VOMS extension, query VOMS servers for details of that user.
  3. if the certificate has no VOMS extension, obtain FQAN from some static configuration file.

Additional groups may be added during the id-user phase.

This is done by adding principal(s) corresponding to the group(s) the user is a member of.

The id-group phase is for adding groups

The login-request may be rejected in this phase in the user supplies incorrect

For example, group-membership could come from the users' VOMS extensions in their proxy certificate.

id-user phase

The id-user phase identifies the user as an individual. This identifies information like the user's UID. Typically this will be done by a single plugin.

Once the id-user phase is completed then the Subject is made read-only and the account phase is undertaken.

account phase

The account phase checks whether the user is allowed to log into dCache. This phase takes the established identity of the user and asks each plugin whether the user is allowed to log in. If any plugin says "no" then the user is denied.

If no plugin says "no" then the session phase is started.

session phase

The session phase establishes the session for the user. This includes establishing account metadata (e.g., home directory, root directory), logging that the user has been allowed access to dCache, etc.

Once this phase is complete then the user's information is returned to the door.