 |
 |
Hi Brian, Right, I get it. Gerri and Andreas, what do you think here? It would seem reasonable to define a plug-in that would be able to augment the XrdSecEntity object before returning it. One issue I see here is to come up with a strict ownership scenario for the existing members of the XrdSecEntity object that the plug-in would want to replace. Perhaps the addition of a replace method (only one, please)? Andy On Tue, 21 Sep 2010, Brian Bockelman wrote: > Hey Andy, > > If you look at the patch, it's entirely within the confines of the XrdSecgsi module. > > The issue is the XrdSecgsi can dlopen() another module which calls a function with this signature: > > typedef char *(*XrdSecgsiGMAP_t)(const char *, int); > > Here, "const char *" is the string of the DN, and the return value is the username. The patch previously attached gives XrdSecgsi the option to pass the PEM string of the user. > > If I had access to the XrdSecEntity object instead of the PEM string, that would also work. However, just mapping based on the DN is really too restrictive for us. > > Brian > > On Sep 21, 2010, at 11:09 AM, Andrew Hanushevsky wrote: > >> 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 >>> >>> > >