data:Dcache/195/aba

Authorization in dCache

Assume, that dCache is installed and configured including two pools for disk-only files (as it described on data:Dcache/195/server). Now we need to tell dCache, who is actually allowed to write into and read from the pools. The easiest way of enabling attribute based authorization is via the vorole-mapping. For this another set of files have to be edited.

The official documentation for dCache (“dCache The Book”) has a up-to-date chapter about this method: http://www.dcache.org/manuals/Book/config/cf-gplazma-vorole.shtml.

/opt/d-cache/etc/dcachesrm-gplazma.policy

In this file dCache looks up, which methods for authorization are enabled and in which order they are to apply (there may be up to 5 different methods). For our purpose we only need to activate gplazmalite-vorole-mapping:

kpwd="OFF"
gplazmalite-vorole-mapping="ON"

Accordingly two other variables need to be checked (remember their value):

# Built-in gPLAZMAlite grid VO role mapping
gridVoRolemapPath="/etc/grid-security/grid-vorolemap"
gridVoRoleStorageAuthzPath="/etc/grid-security/storage-authzdb"

/etc/grid-security/grid-vorolemap

In the grid-vorolemap the first part for attribute based authorization is done: mapping of user roles onto user names. This file may be generated automatically, but it is very easy maintainable by hand. However, there is no template shipped with the installation of dCache, so one has to create it at /etc/grid-security/grid-vorolemap.

"*" "<group>" <username>

This may look like this.

"*" "/ops" ops001

This line introduces the mapping of every possible DN (the asterisk is used as wildcard, but a specific DN is also valid) together with the attribute /ops onto the user “ops001”. This attribute can also reflect the role a user came with:

"*" "/<group>/<subgroup>" <username>
"*" "/<group>/Role=<role>" <username>

At this point it does not matter which user names are used for the mappings as these do not have to be real existing unix useraccounts. In order to compensate for this, the storage-authzdb file is needed.

/etc/grid-security/storage-authzdb

Like said before, this file is needed in order to give the “virtual users” employed in the grid-vorolemap proper uid and gid.

authorize <username> read-write <uid> <gid> / / /
authorize ops001 read-write 22001 5850 / / /

Besides this the very first (non-commented) line must specify the version of the storage-authdb format: “version 2.1”.

The three slashes at the end of the line exist mostly for legacy reasons. Have a look at dCache - The Book (http://www.dcache.org/manuals/Book/config/cf-gplazma-authzdb.shtml) for further details.

/opt/d-cache/etc/LinkGroupAuthorization.conf

Lastly dCache needs to know, which users and roles are to be allowed working with defined link groups. This is configured inside /opt/d-cache/etc/LinkGroupAuthorization.conf. We can either allow any authenticated user and role, or restrict to known VOs.

LinkGroup default-linkGroup
*/Role=*

or

LinkGroup default-linkGroup
<group>
<group>/<subgroup>
<group>/Role=<role>

create directory structure

# insert domainName value
domainName=fzk.de
 
for vo in dgops medigrid c3grid ingrid textgrid wisent hepcg kerndgrid astrogrid dgtest gdigrid progrid partgrid fingrid lifescience education bwgrid dgcms aerogrid bisgrid bauvogrid biz2grid bioif interloggrid mosgrid
do
mkdir /pnfs/$domainName/data/$vo
done
 
for dir in `ls /pnfs/$domainName/data`
do
  uname=$(grep -m1 $dir /etc/grid-security/grid-vorolemap | cut -d' ' -f 3)
  uid=$(grep $uname /etc/grid-security/storage-authzdb | cut -d' ' -f 4-5 | sed 's/ /:/')
  chown $uid /pnfs/$domainName/data/$dir
done
 
ls -dln /pnfs/fzk.de/data/*