 |
 |
If I understand you right you want to allow every authentication class to load a translation module which implements <Protocol>_Replace(XrdSecEntity &entity); In case of Brians requirement one can add the PEM Proxy to the Endorsements and then use the proxy for any kind of translation in the Replace method. So there is probably no need for a dedicated argument other then XrdSecEntity. It would be good if the replace method name is local to each authentication module to apply different translations for different protocols at the same time. The main shortcoming in all that is, that there is only place for either the original values OR the mapped ones, so probably the real identity get's often lost after mapping because the mapping is often not 1:1. Otherwise I like the idea. Cheers Andreas. 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 >>>> >>>> >>>> >> >>