Duane Merrill wrote:
You can obviate the complexity of sections 7.3 and 7.5 only if section 7.7 is mandatory (with a 'MUST' wording), which means you force every middleware to implement immediately the 3 types of Authorization tokens.
In fact, you can NOT force that. This is the reason why I used the 'SHOULD' wording in section 7.7, and this forces the Information System to provide the list of Authorization tokens and transport methods really accepted by each grid Service.
I *strongly* disagree; PGI does need to force that. The goal is not to demand that *all* middleware endpoints be *fully* interoperable; just those that are advertised outside of that infrastructure. And if a particular endpoint is PGI-compliant, there is no reason it shouldn't be able to accept the two major credentialing mechanisms (SAML, AC), particularly since we're defining them to be equivalent.
While I agree that a single security model should be the ultimate goal (for all the reasons you already stated), I see technical problems in having it implemented in all infrastructures, at least in the medium term. That was the reason why the initial work within PGI was focused on having a small set (ideally, two) of security profiles and having the clients sustain the burden of supporting both and deciding which one to use--which seems reasonable as it is the client responsibility to acquire the appropriate credentials. Just to describe one of the technical problema I am alluding at, in CREAM we use an external component called gLExec to perform Grid user ID -> Unix user ID mappings. At the moment, gLExec supports X509 (proxy) certificates with VOMS extensions only, and there is no way (apart from rewriting a significant part of it) to make it support anything else. While gLite is going to migrate to a new authorization framework, it is still (very early) work in progress. And to make things worse, CREAM is unable to bypass gLExec easily: gLExec is called once by CREAM, and once by BLAH, which is a batch system abstraction layer which provides a single interface to multiple batch systems (and thus is used by CREAM to support LSF/PBS/SGE/...). Neither gLExec nor BLAH are under our (=CREAM developers) control, and modifying CREAM to get rid of them when submitting jobs through a PGI compliant interface is a nontrivial work which requires some significant effort. I understand that these are gLite-specific, low level details, but maybe other middlewares have similar issues. I also understand that the software and the infrastructures are going to evolve anyway, but in some situations evolution happens quite slowly. In my opinion, having e.g. two well defined PGI security profiles, such that existing infrastructures can easily support at least one of them would be better than the current situation in which everybody implements something different. It would be a compromise, of course, and the ideal long term solution would be to converge to a single profile, but I'm unsure whether aiming right now at this long term solution would be a good idea. Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233