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
>
>