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

Configuring the gplazmalite-vorole-mapping Plugin

The gPlazma policy file contains two lines for this plugin.

# Built-in gPLAZMAlite grid VO role mapping

The second is the storage-authz-db used in other plugins. See the above documentation Configuring storage-authzdb for how to create the file.

[return to top]

Preparing grid-vorolemap

The file is similar in format to the grid-mapfile, however there is an additional field following the DN (Certificate Subject), containing the FQAN (Fully Qualified Attribute Name).

"/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms" uscms01
"/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms/Role=cmsprod" cmsprod

Therefore each line has three fields: the user’s DN, the user’s FQAN, and the username that the DN and FQAN combination are to be mapped to.

The FQAN is sometimes semantically referred to as the role. The same user can be mapped to different usernames depending on what their role is. The role is determined by how the user creates their proxy, for example, using voms-proxy-init. The FQAN contains the user’s Group, Role (optional), and Capability (optional). The latter two may be set to the string NULL, in which case they will be ignored by the plugin.

If a user is authorized in multiple roles, for example

"/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms" uscms01
"/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms/Role=cmsuser" cms2847
"/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms/Role=cmsphedex" phedex
"/DC=org/DC=doegrids/OU=People/CN=Gina Carlson 584065" "/cms/uscms/Role=cmsprod" cmsprod

they would be mapped to the username corresponding to the role found in the proxy that the user creates for use by the client software. Starting in dCache 1.8, if the user actually creates several roles in their proxy, authorization (and subsequent check of path and filesystem permissions) will be attempted for each role in the order that they are found in the proxy. In a griftp URL, the user may also explicity request a username


in which case other roles will be disregarded.

[return to top]

Authorizing a VO

Instead of individual DNs, it is allowable to use * or "*" as the first field, such as

"*" "/cms/uscms/Role=cmsprod" cmsprod

In that case, any DN with the corresponding role will match. It should be noted that a match is first attempted with the explicit DN. Therefore if both DN and "*" matches can be made, the DN match will take precedence. This is true for the revocation matches as well (see below).

Thus a user with subject

"/DC=org/DC=doegrids/OU=People/CN=Ted Hesselroth 897321"

and role


will be mapped to username cmsprod via the above storage-authzdb line with "*" for the DN, except if there is also a line such as

"/DC=org/DC=doegrids/OU=People/CN=Ted Hesselroth 898521" "/cms/uscms/Role=cmsprod" uscms01

in which case the username will be uscms01.

[return to top]

Revocation Entries

To create a revocation entry, add a line with - as the username, such as

"/DC=org/DC=doegrids/OU=People/CN=Timur Perelmutov 623542" "/uscms/production" -

or modify the username of the entry if it already exists. The behaviour is undefined if there are two entries which differ only by username.

Since DN is matched first, if a user would be authorized by his VO membership through a "*" entry, but is matched according to his DN to a revocation entry, authorization would be denied. Likewise if a whole VO were denied in a revocation entry, but some user in that VO could be mapped to a username through his DN, then authorization would be granted.

[return to top]

More Examples

Suppose that there are users in production roles that are expected to write into the storage system data which will be read by other users. In that case, to protect the data the non-production users would be given read-only access. Here in /etc/grid-security/grid-vorolemap the production role maps to username cmsprod, and the role which reads the data maps to cmsuser.

"*" "/cms/uscms/Role=cmsprod" cmsprod
"*" "/cms/uscms/Role=cmsuser" cmsuser

The read-write privilege is controlled by the third field in the lines of /etc/grid-security/storage-authzdb

authorize cmsprod  read-write  9811 5063 / /pnfs/ /
authorize cmsuser  read-only  10001 6800 / /pnfs/ /

Another use case is when users are to have their own directories within the storage system. This can be arranged within the gPlazma configuration files by mapping each user’s DN to a unique username and then mapping each username to a unique root path. As an example, lines from /etc/grid-security/grid-vorolemap would therefore be written

"/DC=org/DC=doegrids/OU=People/CN=Selby Booth" "/cms" cms821
"/DC=org/DC=doegrids/OU=People/CN=Kenja Kassi" "/cms" cms822
"/DC=org/DC=doegrids/OU=People/CN=Ameil Fauss" "/cms" cms823

and the corresponding lines from /etc/grid-security/storage-authzdb would be

authorize cms821 read-write 10821 7000 / /pnfs/ /
authorize cms822 read-write 10822 7000 / /pnfs/ /
authorize cms823 read-write 10823 7000 / /pnfs/ /

Starting with dCache 1.8, regular expressions are supported in the /etc/grid-security/storage-authzdb file. Substitutions by regular expression group are also permitted. Place a regular expression in the username field of the storage-authzdb file. Any groups in the regular expression (defined by enclosure in parentheses) can be referred to in later fields of the line, and the corresponding susbstitution will be made when the file is read. For example, the above lines for granting users individual directories can be replaced with

authorize cms(\d\d\d) read-write 10$1 7000 / /pnfs/$1 /

in which case cms821 matches cms(\d\d\d) and the group (\d\d\d) is substituted in 10$1 to yield 10821 and in /pnfs/$1 to yield /pnfs/, and so on.