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