Grid-mapfile based authentication for DynaFed

The Dynamic Federation project (DynaFed) is a good way to federate existing Grid storage as well as making S3 based object stores available for Grid storage. To access DyanFed, the webdav/https protocol is used.

The default authentication for accessing the storage backend is based on X.509 certificates and voms proxies. In that case, the user has to use grid tools to contact a voms server to authenticate and create a X.509 proxy locally on the client machine. This proxy can then be used by tools that support it to list and access files behind DynaFed. However, that kind of authentication must be supported by the tool used. It will for example not work using a web browser.

In addition to the build-in authentication, DynaFed also supports Python based scripts to handle the authentication. One of the standard Grid authentication method is to authenticate against a so called grid-mapfile which is usually created by tools like edg-mkgridmap.
We implemented this grid-mapfile lookup into DynaFed using a python script. The way it is implemented is similar to how xrootd based federations are using authentication.

To use the python based authentication module, one needs to add to /etc/ugr/ugr.conf

glb.authorizationplugin[]: libugrauthplugin_python27.so authplug1 ugrauth_gridmap isallowed

and the python script ugrauth_gridmap.py needs to be in /etc/ugr/ugr.conf . Depending on OS version, libugrauthplugin_python26.so may be needed instead of libugrauthplugin_python27. The correct file can be found in /usr/lib64/ugr/.  
To have the authentication working correctly, one needs to have a grid-mapfile and an accessfile in /etc/grid-security/.

Let's assume data for the Atlas experiment can be accessed through DynaFed using the https://WEB.SERVER.COM:8443/myfed/S3-Atlas/datadisk then in accessfile there should be a line:

/myfed/S3-Atlas/datadisk atlas rl

which would allow anyone who belongs to the Atlas VO to read and list content under /myfed/S3-Atlas/datadisk/. Similar line can be added for other endpoints or other groups, e.g. for the atlas-production role.

To be able to decide if a user belongs to a specific VO or role, to the Atlas VO in the example above, the file /etc/grid-security/grid-mapfile needs to be generated. 

Since a single user could have the own certificate registered with different VOs, the standard Grid approach can't be used since it associates each user certificate with only exactly one VO or role. To allow a certificate to be associated with any role or VO that it is registered with, one needs a configuration file for each voms server and role that a VO supports, for example for the Atlas VO one could have:

•  /etc/edg-mkgridmap-atlas.conf
•  /etc/edg-mkgridmap-atlas-prod.conf
•  /etc/edg-mkgridmap-atlas-lcgadmin.conf

As an example,  /etc/edg-mkgridmap-atlas-prod.conf could have the content:

group vomss://lcg-voms2.cern.ch:8443/voms/atlas?/atlas/Role=production atlas-prod
group vomss://voms2.cern.ch:8443/voms/atlas?/atlas/Role=production atlas-prod

For each supported VO, there need to be the voms server config files be present in /etc/.

Then, the grid-mapfile, for example for authenticating users of the Belle-II and Atlas VO, can be created with a script like:

#!/bin/bash
TMPFILE=/tmp/gridmap.out
if [ -f $TMPFILE ]
then
  rm $TMPFILE
fi
touch $TMPFILE
for VO in belle belle-prod belle-lcgadmin atlas atlas-prod atlas-lcgadmin
do
  edg-mkgridmap --conf=/etc/edg-mkgridmap-$VO.conf --output=- >>$TMPFILE
done
sort $TMPFILE >/etc/grid-security/grid-mapfile

After all is in place, httpd and memcache need to be restarted and authentication without a voms proxy should work based on the grid-mapfile. The script that generates the grid-mapfile needs to be executed periodically, e.g.in a cron job.

More detailed information about the installation and authentication in dynafed can be found here.