Hi, Artem

I noticed yesterday that the head of the xrootd CVS does no longer build with 
autotools (must have been some change in the last week), so I'll investgate 
and try to fix it asap.

The error you are getting is due to a missing dependency (tokenauthz) you can 
find on the arda www area: When I still was at CERN working for ALICE, I had 
set up this page for alice downloads of xrootd (we had a separate autotools 
build, before most of this went into the xrootd CVS)

http://project-arda-dev.web.cern.ch/project-arda-dev/xrootd/tarballs/

I don't know which version Andreas is currently using, but he is be the best 
source for how to operate the XrdTokenAuthz, because he implemented most of 
it and only AliEn is currently enabled for this method. I cannot test here, 
because I don't have an AliEn setup.

Cheers,
Derek



On Friday 03 February 2006 16.17, Artem Trunov wrote:
> Hi, Derek!
>
> Thanks for all explanations! I am now trying to actually setup servers
> for Alice.
>
> Since this libTokenAuthzOfs library is replacing libXrdOfs in the
> xrd.fslib directive , is it compatible with original?
>
> I tried to compile xrootd (20060105-0311) with token support, but got the
> following:
>
> XrdTokenAuthzOfs.cc:8:25: TTokenAuthz.h: No such file or directory
> XrdTokenAuthzOfs.cc: In member function `virtual int
>    XrdTokenAuthzOfsFile::open(const char*, int, unsigned int, const
>    XrdSecEntity*, const char*)':
> XrdTokenAuthzOfs.cc:71: `TAuthzXMLreader' undeclared (first use this
> function)
>
> ..etc...
>
> For my very first tests, I can probably use production alien installation
> at our site with it's token library, but I do need to be able to compile
> xrootd with it for normal production installations...
>
> Is this just packaging problems? Or there dependencies on ROOT?
>
> Artem.
>
> On Thu, 2 Feb 2006, Derek Feichtinger wrote:
> > Hi, Artem
> >
> > On Thursday 02 February 2006 11.10, Artem Trunov wrote:
> > > Hi, Derek!
> > >
> > > Thanks for detailed explanations! I now see that we indeed can't get
> > > away with generic setup of xrootd clusters, and will have to run
> > > AliEn-enabled version. It's not a big problem by itself, buth there is
> > > a complication - we have to maintain authorization database on every
> > > leaf node - not a nice thing...
> >
> > No, I was too unclear in my previous mail.
> > The leaf nodes are completely generic. They all contain the same little
> > policy file where keys per VO are defined and maybe some special rules,
> > if required (you can slice of part of the namespace for a certain VO,
> > etc). The authorization decision is taken by the catalog. The token you
> > get contains everything that the xrootd needs to determine the access
> > rights. The method just guarantees that the catalog's decision is safely
> > forwarded to the xrootd.
> >
> > Conceptually, the catalog is the owner of all files in this method
> > (however, we provided a possibility in the policy file, where local site
> > policy can be enforced, since this is a requirement from some sites).
> >
> > > If I understad you correctly, you prefere to avoid authorization on the
> > > master, and push it to leaf nodes? What do you think about reverse
> > > solution - authorization only on the master? This way the master is
> > > also you authorization server,  and leaf nodes are generic...
> >
> > We want to avoid authentication on the redirector, because it is slow
> > (and as a consequence, I cannot do full authorization, because this
> > depends on prior authentication). The redirector should work in a way
> > that it can redirect clients as fast as possible, leaving the grunt work
> > to the leafs.
> >
> > For your approach, you would need to modify the xrootd protocol in a way
> > that the redirector informs the leaf that your access is allowed, because
> > your client is not proxied through the redirector to the leafs, but
> > really makes an own connection to the leaf node: If you know the name of
> > the file and on which leaf it resides, you can just go there directly
> > without ever contacting the redirector. So, in the present system you
> > need authen and authz on the leafs.
> > I think this is ok, because the additional effort is then optimally
> > distributed over the servers and you don't have a bottleneck in a
> > centrally important machine.
> >
> > Cheers,
> > Derek
> >
> > > Artem.
> > >
> > > On Thu, 2 Feb 2006, Derek Feichtinger wrote:
> > > > Hello, Artem
> > > >
> > > > > > we would be forced to run it on both redirectors and leaf nodes
> > > > > > (awful).
> > > > >
> > > > > Could you please explain a bit more, since this contradicts to
> > > > > Andy's answer. I.e. what will happen if Alien client carrying authz
> > > > > token comes to a server w/o AliEn authz lib?
> > > >
> > > > Ok. In our current design, the client asks the xrootd for the LFN.
> > > > The PFN is contained in the encrypted token from the catalog together
> > > > with the permission information and the requester's certificate
> > > > subject (the token can contain entries for multiple files). But the
> > > > redirector needs to know the PFN in order to perform its duty, so it
> > > > has to decrypt the token.
> > > >
> > > > xrootd gets the request as a normal URL:
> > > > root://server/LFN?authz=encrypted-token&vo=VO-name
> > > >
> > > > This was done, so that even the names of the physical files are
> > > > hidden from outside (and we wanted to have this in mainly to show
> > > > what possibilities the method offers, also for the paper we presented
> > > > at SC05). However, this forces us to decode the token already on the
> > > > redirector.
> > > > We could drop this hiding of the PFN, or we could think of a setup
> > > > where we still perform the token decryption on the redirector, but
> > > > without doing any authentication there. Authentication will then be
> > > > done on the leaf node together with another token decryption. The
> > > > token decryption is pretty fast (<10 ms).
> > > > I think this would be a good solution.
> > > >
> > > > The whole mechanism has the advantage that it can be easily
> > > > implemented for every catalog and that a single server can also
> > > > easily work securely for a number of different VOs (the catalog and
> > > > the storage elements just need to know each others public keys.
> > > > That's the central part of the encryption) Here is a link to the SC05
> > > > paper, if you are interested:
> > > >
> > > > Paper: http://people.web.psi.ch/feichtinger/doc/authz.pdf
> > > >
> > > > (slides, somewhat flashy and ppt format):
> > > > http://people.web.psi.ch/feichtinger/doc/Grid05_dfeich.ppt
> > > >
> > > >
> > > > Cheers,
> > > > Derek