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