[Pgi-wg] OGF PGI - Security Model

[Duane Merrill]

So, what you're saying is that it is, for all intents and purposes,
infeasible for the CREAM BES to support an attribute authorization scheme
other than VOMS-style-ACs-inside-EECs/PCs.  This leads me to draw the
following conclusion:

*Don't bother advertising CREAM BESs as inter-middleware services*.
Unicore/GenesisII/etc. infrastructures don't have the means for clients
to obtain PCs or EECs that have VOMS-style ACs signed within them, so in all
reality your CREAM BESs will never be used by those middlewares anyway.  If
you need to share your resource across middleware domains, stand up a BES
that can support *both* types of credentialing mechanisms instead.

The issue holding the client back is that they have a signed SAML assertion
that cannot be traded for a signed VOMS-style AC without the involvment of a
hypothetical third-party attribute authority.  The implementation work
necessary for such infrastructure would be just as substantial (if not more
so) than the modifications necessary for CREAM, and would become obsolete as
we move towards the "eventual goal".

Now, if your CREAM BES could support PGI-SAML embedded within PCs, it would
be trivial for the client to create a proxy certificate for itself with the
SAML attribute embedded within......

-Duane




On Thu, Mar 26, 2009 at 9:24 AM, Moreno Marzolla <moreno.marzolla at pd.infn.it
> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090326/deef12a5/attachment.html