 |
 |
Hi Brian, Well, actually I would say that the defaults xrootd provides could be considered rudimentary but that was done by design since we couldn't foretell what kind of security model people would want in the end. The architecture, however, is open-ended and you can do what you want within the plug-in framework. 1) The authentication plugin is the place where we figured someone would transform the cert (or whatever) to a set of identifiers to be used by the authorization plug-in. The object here is the XrdSecEntity which includes pointers to extended attributes as well as the original cert chain. 2) The XrdSecEntity object is passed in total to the authorization plug-in to do whatever authorization it needs to do on whatever was provided in the that object. So, yes, the authenticatin plug-in needs to provide the appropriate identity information for authroization to be able to do its thing. So, I think you can do whatever it is you need to do within the existing framework. Just look at the XrdSecEntity and the XrdAccAuthorize object that is used to feed the authorization plugin. I think you'll find all the basics already there. Andy P.S. If, you feel that the existing gsi or ssl auth plug-ins do not fill in the appropriate members in the SecEntity object then that should be addressed within the confines of those plugins. On Mon, 20 Sep 2010, Brian Bockelman wrote: > Hi all, > > It's always bothered me (and my site admins!) that Xrootd uses relatively rudimentary authorization compared to other deployed grid tools. Attached is a patch aimed to fix this. > > It changes the way the GSI security module maps a remote user to a local username. Currently, it does this based on the certificate's DN and can dlopen() a shared library to provide the mapping, or just do a normal grid-mapfile lookup. The attached patch additionally adds a means for Xrootd to dlopen() a shared library which is mapped the PEM-formatted certificate chain instead of the DN. This allows the loaded module to make mapping decisions based on other things, such as VOMS attributes. > > You can download sources for the loadable module I'll be using here: > > svn://t2.unl.edu/brian/XrdLcmaps > > This module hands off the cert chain to the LCMAPS library developed in gLite, which can enforce different flexible authz policies. At our site, this involves GUMS, but it should support any authz policy deployed in EGI or OSG. > > Let me know your thoughts, > > Brian > >