Last modified 7 years ago Last modified on 12/03/10 14:15:11

Motivation for a new gPlazma

dCache is about to enter a number of new communities. Common to these communities is the need for increased flexibility and control over authorizing access to files. In addition, WLCG has asked for more flexibility in this regard as analyses and user content doesn't follow the neat rules of production workflows.

Although dCache has recently received support for NFS4 ACLs, those ACLs are expressed in terms of user IDs and group IDs. With current dCache, it is technically possible to map each individual user to a unique user ID; however, this requires a static mapping that is defined a priori. A site will perform authorization of groups, not individuals, so such a static mapping of all possible users is unwanted.

The new communities have also stated that ACLs must be manageable by end users, not only system administrators. Administrators typically only care about groups of users (say, authorize all Atlas users), whereas it is the end user that wish to restrict or provide access to individual users. For that reason we need to provide a flexible interface through which end users can customise ACLs. The obvious choice is to provide an HTML user interface through the HTTP/WebDAV door for this use-case. While ACLs work with user IDs and group IDs, these IDs are unknown and meaningless to end users. Therefore we need a mechanism to map those IDs back to meaningful descriptions of the users and groups. Such a reverse mapping does currently not exist in dCache.

We also have several issues concerning how we treat the concept of users within dCache. To overcome the above limitations, several components have started to use protocol-specific user identification to obtain credentials unique to users. These components include stage protection, pin manager, and space manager, which deal with DNs and FQANs. This is to workaround the limitations of user and group handling in dCache. However those workarounds also make those components and mechanisms protocol specific. Kerberized protocols have different identifies, and what about password based protocols like FTP or HTTP? They don't fit into this model. For this reason we need a uniform, protocol independent way of dealing with users and groups.

We have currently several internal representations of user credentials:

  • the messages that are send to GPlazma,
  • the record we get back from GPlazma,
  • an authorization record, and
  • the standard Java (JAAS) Subject class.

Some components even store protocol specific identifiers like DNs and FQANs in custom databases.

A final issue is how we assign default permissions and decide the ownership of new directories and files. This decision is currently door specific. This introduces lots of inconsistencies that are bound to confuse our users.

gPlazma2 and JAAS

User information in the new gPlazma is represented by classes from Java Authentication and Authorization Service (JAAS). Especially the notions of Principals and Credentials have been taken from JAAS. Credentials are raw security attributes, such as Kerberos tickets or X.509 certificates. Credentials can be PublicCredentials (public keys, usernames) or PrivateCredentials (passwords, private keys). Principals are user identity information that can be extracted from Credentials. Principals alone do not assert anything about the authentication level. A principal can be any user information, from a user-supplied login-name to a client-IP address to a X.509 distinguished name. Whether actual access is granted to a certain part of the system is part of an authorization decision based on the principal in question.

Principals needed in gPlazma

Some of the principals used in gPlazma can be taken from existing implementations, while some will have to be implemented in dCaches common-module. The following principals are needed by different components:

UID org.dcache.auth.UidPrincipal
GID org.dcache.auth.GidPrincipal
FQAN org.dcache.auth.FQANPrincipal
DN org.globus.gsi.jaas.GlobusPrincipal (?)
Username org.dcache.auth.UserNamePrincipal
Client-IP org.dcache.acl.Origin

Credentials needed in gPlazma


Types of plugins

There are four types of gPlazma plugins. Classes providing functionality for one or more of the plugin types should implement the respective gPlazma-plugin interfaces.

  • Authentication: Verify credentials and extract principals. Principals sent from doors are not touched.
  • Mapping: Map from one kind of principal (DN, FQAN) to another principal. Map from principals to UID, GID. Offer reverse mapping.
  • Account: Global blacklisting, rejection of non-authorized or illegal principal sets
  • Session: Obtain session metadata upon login. Such session metadata can e.g. be home directory or root directory, needed by certain protocols.

gPlazma architecture

Processing of the plugins follows the Strategy pattern.

A rough overview in form of an UML diagram is presented below:

Plugin configuration

gPlazma plugin execution order is defined using a PAM-like configuration file. An example of such a configuration file could look the following way:

  <type>  <control>  <plugin>  [<configuration>]
# a comment
  auth    sufficient x509
  auth    required   kerberos
  map     sufficient gums
  map     required   kpwd
  account required   blacklist
  session required   dcachesession
  • Legal PAM types: auth, map, account, session
  • Legal values for control (with priorities in brackets): require(1), sufficient(1), requisite(2), optional(3)
  • Control can take a DEFAULT entry, see the plugin configuration file below.

Plugin framework

We decided to use our own plugin framework, based on JAR autodiscovery. Plugins are distributed in JARs, containing a configuration file that specifies the plugins that ship with the JAR. Such a file could be called META-INF/gplazma-plugins.xml. An example:


The plugins

X509 Plugin (Authentication)

It extracts X509 DN and FQAN Principals from X509 Certificate Chain.

Wrapper around gPlazma (Authentication, Mapping, Session)

  1. Authenticate behaves as X509 Plugin for X509 Certificate Chain.
  1. Mapping (principals, authorizedPrincipals ) converts the

union of the two set provided as an parameters, and convert them into the gPlazma input, similarly to what is being done in NewHandlerToOldGPlazma adapter. Old gPlazma gPlazma authorization is performed, the Resulting AuthorizationRecord is converted into a Set<Principals> and added to authorized Principals. AuthorizationRecord is stored in HashMap with SessionId as a key.

  1. GPlazmaSessionPlugin will extract the AuthorizationRecord from the HashMap (deleting it to prevent memory leak), verify that authorized principals are the ones we expect for this AuthorizationRecord (Enough to check uid and active gid? ). Use root and home attributes from AuthorizationRecord to populate Set<SessionAttribute> attributes.

Globus Gridmapfile (Mapping)

Let DN be set of all DNs. Let LN be a set of all loginNames. Gridmapfile mappings M can be defined as M={ (m) | m ? DN x }. Let P be a set of Principals. GPlazmaMappingPlugin can be thought of as taking two Sets of Principals as input and producing a two set of principals as output. Let G be the set of GPlazmaMappingPlugins; Then G={ (g) | g ? (PxP)x (PxP)} Now gridMapfileGpazmaPlugin corresponding to m ? M can be defined as { (g) | g ? G and ? ((P1,P2),(P3,P4)) ? g P1=P3 and P2 ? P4 and ? p ? P4P2 | p ? LN and ? dn ? P1 | (dn,p) ? m }. What this means is that gridMapfileGpazmaPlugin does not modify the set of authenticated principals (P1=P3), it does not delete authorized principals (P2 ? P4) and for any Principal p that was added to authorized Principals the following is true: it is a LoginName and there exists a DN in first set, that is mapped into the LoginName by m.

VO-role map (Mapping)

  1. VoRoleMap file consists of the lines following pattern

<DNPattern> <FQANPattern> <Username>

Vorolemap function goes throught all the lines in Vorolemap file and maps any (DN, FQAN) combination into a username, if DN matches DNPattern and FQAN matches FQANPattern into a corresponding Username. If If FQANPattern is “match all”, then FQAN presence in a pair is not required.

  1. VorolemapPlugin implements GPlazmaMappingPlugin, it does not modify the set of authenticated principals, it perform mapping on basis of the presence of the DNPrincipal and FQANPrincipals in authenticated Principals set. If DN and FQAN corresponding to a DNPrincipal and FQANPrincipal in authenticated Principals set are mapped into a Username by the Vorolemap function, then VorolemapPlugin add a LoginPrincipal corresponding to Username to authorized Principals set.

Storage-authdb (Mapping, Session)

Storage-authdb consists of lines, each line (excluding comments, empty lines, etc.) has a following syntax:

authorize <username> <permission> <uid> <gid> <home> <root> <path>

Each such line can be considered a storage-authdb record with fields “username”, permission, ..., etc. Permission can be read-write or read-only. If authorizedPrincipals set contains a LoginName principal with name equivalent to the username record in Storage- authdb, then it adds Uid and Gid principals to authorizedPrincipals. The session implementation would do the lookup of the storage-authdb record for each LoginName present in authorized set, and if one found, it would generate a Home and Root SessionAttributes.

Question (Timur): how do we indicate that this Subject has only read privilages? I think this can be a session attribute as well.


  1. These are external services that perform mappings from DN

names and FQANs into "Usernames2.

  1. Corresponding gPlazma plugins would extract the DN name

and the collection of FQAN names from the set of authenticated principals, and send these as the strings to corresponding services using service specific protocol. The returned “Username” would be embedded into a LoginName principal and added to the list of authorized principals.

SAZ (Mapping)

In order to be effective, it needs to be run first in list of MappingPlugins. For each Principal in authenticated principals it would make a call to external service called SAZ. SAZ has an option to indicate that the Principal is banned from the site, in this case SAZPlugin fails (throws the exception).

dCache kpwd (Mapping, Session)

  1. Kpwd Plugin iterates over the authenticated principals (step 1), then over the authorized principals (step 2). For each authenticated principal that is a DN Principal it performs the function similar to gridmapfile, but on basis of the mapping session of kpwd file. For each Authorized LoginName principal (including those that were added during the step 1) it tries to find a login record from kpwd file. If this record is found, its list of “authorized DNs” is compared with authenticated principals. If a match found, the uid and gid from the record are added as UidPrincipal and GidPrincipal to authorized Principals.
  1. During the session call the same lookup of the kpwd file record is performed as in step 2 above, but this time its home and root fields are used to create a Home and a Root SessionAttributes?.

Transitioning dCache to the new gPlazma architecture

The new gPlazma should only be accessed as a well-known cell, not as a module. Adapting the doors to the new gPlazma architecture follows the following path:

  1. Implement legacy gPlazma handler.
  2. Update doors to populate subject field of PoolMgrSelectPoolMessage (and children).
  3. Update SpaceManager to use subject rather than AuthorizationRecord.
  4. Remove AuthorizationRecord from those Messages/protocolinfo.

Specific Doors


Two alternative approaches have been identified:

  1. The door verifies and extracts DN/FQAN and sends them as principal to gPlazma.
  2. The door sends X509Chain as credential to gPlazma and gPlazma extracts DN/FQAN principals

Optionally the door passes username and password to gPlazma as PublicCredentials.
Optionally the door passes the X.509 certificate and the private key for delegated credentials (Grid proxies) along as private credentials.


The door verifies the Kerberos Ticket and sends a KerberosPrincipal to gPlazma.

Optionally the door passes the username as a public credential.
Optionally the door passes client UID + client GID public credentials.


The current AuthorizationRecord must be mapped to a Subject.
The current User object must be updated to a Subject in all CompanionMessages/Interactions from SRM to SpaceManager.

Passing the Subject to gPlazma

  • Principal information, regardless of whether it still needs further processing, mapping or authorization decisions, is already passed as a Principal.
  • Every different credential is passed as a different credential class.