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).

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

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.

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

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

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

in which case the username will be uscms01.

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

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.

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.

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

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

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

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

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/fnal.gov/data/cms$1 to yield /pnfs/fnal.gov/data/cms821, and so on.