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:

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:


(slides, somewhat flashy and ppt format):