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