 |
 |
Hi, Derek! Thanks for all explanations! I am now trying to actually setup servers for Alice. Since this libTokenAuthzOfs library is replacing libXrdOfs in the xrd.fslib directive , is it compatible with original? I tried to compile xrootd (20060105-0311) with token support, but got the following: XrdTokenAuthzOfs.cc:8:25: TTokenAuthz.h: No such file or directory XrdTokenAuthzOfs.cc: In member function `virtual int XrdTokenAuthzOfsFile::open(const char*, int, unsigned int, const XrdSecEntity*, const char*)': XrdTokenAuthzOfs.cc:71: `TAuthzXMLreader' undeclared (first use this function) ..etc... For my very first tests, I can probably use production alien installation at our site with it's token library, but I do need to be able to compile xrootd with it for normal production installations... Is this just packaging problems? Or there dependencies on ROOT? Artem. On Thu, 2 Feb 2006, Derek Feichtinger wrote: > 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 >