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
|