[Pgi-wg] OGF PGI - Security Model

Thu Mar 26 09:24:36 CDT 2009

Hi Duane,

BES was proposed as a standard interface for job submission. Our initial 
aim was to understand how/if we could adopt this interface in our 
infrastructures. Obviously this interface alone will not make the 
infrastructure fully interoperable but it would be a step in the right 
direction.

One of the constraints that we have is that our infrastructure is based 
around VOMS-style-ACs and this will not change this in the short term. I 
would imagine any other infrastructures using a different AAA scheme 
would have a similar problem.
Adopting the BES interface should not require people to change the AAA 
scheme that they used in their infrastructure.

What we require is a method of using BES with VOMS-style-ACs. We may end 
up with multiple specification that explain how BES is used with 
different AAA schemes. This would highlight the real situation and we 
have different "Grid Islands" which can't interoperability due to the 
different AAA schemes used.

If interoperability between these islands is required we need to address 
the AAA issue but that should not affect our adoption of BES.

Laurence

Duane Merrill wrote:
> 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 <mailto: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
>     <mailto:moreno.marzolla at pd.infn.it>         Phone: +39 049 8277103
>     WWW  : http://www.dsi.unive.it/~marzolla
>     <http://www.dsi.unive.it/%7Emarzolla>  Fax  : +39 049 8756233
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
>   