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