[Pgi-wg] OGF PGI - Security Model

[Moreno Marzolla]

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 at pd.infn.it         Phone: +39 049 8277103
WWW  : http://www.dsi.unive.it/~marzolla  Fax  : +39 049 8756233