Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Christopher J.Walker said:
> Which is what prompted me to wonder this morning why it is desirable
> for all services that use proxies (WMS, FTS and probably others) from a
> myproxy server to write the same code to bless that proxy with voms
> attributes. I'd have thought it better to write the code once in the
> myproxy server.
The WMS renewal daemon is a standalone piece of code (provided by the security group I think rather than the WMS developers). I'm fairly sure that at one point the plan was for it to be used in the FTS too, but it seems that it never happened - as with many things the main clients are the LHC VOs and they no doubt found their own ways to do it so there was no pressure to make a general solution. There is now a plan for an FTS 3 but I'm not sure what they have in mind for this.
In principle it presumably could be integrated with myproxy, but that comes from VDT so we have even less influence on development than we have on EMI, and my impression is that VOMS is not as central to the US grids as it is in EGI, although possibly it's changing.
> "The myproxy server stores certificates" isn't an answer that makes
> sense to me. In other words, from a policy point of view, what's the
> attack vector you are trying to avoid here? An answer of "we didn't
> think of it at the time, so it's not in the spec and it's easiest to
> write the code 5 times" is on the other hand an understandable, if
> somewhat suboptimal answer.
As you've probably realised by now there is no spec for anything! (Well, except SRM, and even there the code doesn't always comply.) We happen to have proxy renewal in the WMS because it was in their design right from the EDG days, back when we did at least attempt to have an architecture. Just for amusement here's the EDG user guide (parts of which were written by me, although I think not the job submission section):
http://marianne.in2p3.fr/datagrid/documentation/EDG-Users-Guide-2.0.pdf
See section 4.3.
Stephen
|