Authorization in DynaFed, Part 2

As we showed previously, there is an easy way to use the information derived from VOMS-server based on grid-mapfiles to authorize a specific user to access a specific part of the dynamic federation. This solution was based on 3 parts:

  1. a grid-mapfile listing the DNs of all users from all supported VOs with all possible roles
  2. a text file (accessfile) that specifies the different privileges for the different parts of the storage federation
  3. a python script that is doing the authentication and authorization based on the 2 previously mentioned files
While in this solution the grid-mapfile and accessfile can be changed anytime without the need to reload/restart the httpd and memcache process, there is also a simpler solution based on the internal authentication methods possible which however needs to restart httpd and memcache after each change. This one will be explained in the following.



Using the built in authentication in Dynafed, one can grant access to a specific part of the federation to a group or single user with:
  1. glb.allowusers[]: GRID-DN /atlas rl
  2. glb.allowgroups[]: atlas /atlas rl

Now, since the GRID-DN is given by a VOMS server lookup, like it is done by the edg-mkgridmap tool as explained previously, both methods can be combined. When using edg-mkgridmap without specifying an output file then the output is sent to stout and can be manipulated before writing to a file:

edg-mkgridmap --conf=/etc/edg-mkgridmap-atlas.conf|awk '{NF=NF-1;print "glb.allowusers[]: "$0" /atlas rl"}' > /etc/ugr/conf.d/atlas-auth.conf

using the same config files as in the blog post about using grid-mapfiles. This example will allow all users to have read and list permission for anything under /atlas using the built-in authentication mechanism of Dynafed.

To allow in addition all production jobs write access to /atlas/datadisk, one can add to /etc/ugr/ugr.conf:

gl.allowgroups[]: atlas/Role=production /atlas/datadisk rwld

Using this kind of authorization/authentication will work much faster than the current grid-mapfile implementation in python, but one has to keep in mind that 
  1. any group specific authorizations will only work with tools that can handle voms proxies, e.g. it will not work in web browsers
  2. when changing the /etc/ugr/conf.d/atlas-auth.conf then it will not be instantly be available in httpd
    1. there is configurable limit in httpd after which all config files are reload
    2. to apply changes instantly, httpd needs to be restarted
      1. the graceful option could be helpful here to not interrupt current requests



Comments

Post a Comment

Popular posts from this blog

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...
Read more

Monitoring Dynafed with ELK

Image
The Dynamic Federation project (DynaFed)  being developed at CERN is intended to federate any number of different types of storage endpoints allowing users to read or write data transparently and efficiently. How it works in a nutshell: A client sends a COPY, GET, PUT, DELETE HTTP request to the DynaFed instance's URL. DynaFed decides which amongst the storage endpoints it federates is the "best" one to handle the request, sorted according to geographic location and available free space. The client receives a 302 redirect link pointing to this storage endpoint with the protocol and authentication tokens necessary for the transaction. The client re-sends the HTTP request directly to this storage endpoint. As we can see, after the redirect link is provided, DynaFed is out of the loop and as such is unaware of whether the client-storage endpoint transaction is successful or not. So while we cannot get this valuable information from Dynafed, we instead are interested i...
Read more

ACAT 2017

The 18th International Workshop on Advanced Computing and Analysis Techniques in Physics Research ( ACAT ) took place in Seattle this week. We presented our work on integrating the dynamic web federation into HEP computing as a poster . The conference focused on the use of machine learning algorithm in physics research with contributions from industry offering effective computing technology to execute workflows employing deep neural nets. These technologies offer solutions to the computing issues the field is facing in light of a great increase in data with a constant computing budget. When the LHC experiments were planned it was assumed that Dennard Scaling would solve this problem for us, it has become clear that this is not the case. It was shown that generative adversarial neural nets may be used to do do simulation, and that supervised learning may provide options for triggering and reconstruction. In some places these technologies are already used. nVidia, Microsoft, and DW...
Read more