[Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ

[Duane Merrill]

Oh, I agree that the Unicore-using-ACs-in-EECs scenario has some logistical
drawbacks for the Unicore callers, particularly when the caller is a user
and not a static service/agent.

Another (better?) way of architecting a Unicore->EGEE bridge would be for
the shared EGEE services to support the extraction of Unicore
(equivalent-to-VOMS-ACs) SAML assertions from the SOAP message header.  The
attributes would carry the same semantic information as VOMS-ACs and, once
distilled, could be wired up the the existing EGEE authz infrastructure.
 This is essentially a "receiver-makes-right" approach.  (In the other
direction, select Unicore endpoints could process and extract the VOMS
information from ACs obtained from proxy certificates during SSL handshake,
extract the VO membership information, and wire it up to their existing
authz infrastructure.)

Honestly, a "receiver-makes-right" approach to interop is the most sensible
for two reasons:

   1. *Not all endpoints in a mixed-grid environment need to interoperate:
   only the services that are intended for cross-grid sharing*.  A
   progressive roadmap to interoperability can save a huge amount of
   development/testing effort (e.g., no need to replace non-standard
   GSI-OpenSSH libraries everywhere; only in select endpoints advertised to
   other grids)
   2. *Some changes to client-side credentialling infrastructure may simply
   not be possible*.  (For example, an EGEE agent could hypothetically
   acquire equivalent SAML attributes for calling into a Unicore service, but
   would be unable to sign them with anything other than a proxy-certificate.
   Thus it would make sense for the select Unicore interop services to support
   proxy-path-validation at the transport and/or message layer.)

-Duane


  On 3/20/09, Moreno Marzolla <moreno.marzolla at pd.infn.it> wrote:
> Duane Merrill wrote:
>> Yes, your certificate authority could sign ACs into PKCs.
>>
>> This would be a reasonable strategy if, for example, your middleware
>> had statically-assigned identities (and statically-associated
>> attributes) and you wanted to call into resources operated by a
>> (idealized) middleware that looks for VOMS-style proxy-certs. (Because
>> the callee middleware knows how to process PC chains with embedded
>> ACs, it also knows how to process your vanilla PKCs with embedded
>> ACs.).
>
> That's correct, but unfortunately the situation is a bit more complex.
> Certification Authorities release certificates without any VO membership
> attributes (at least, the INFN CA does not embed VO information).
> Furthermore, users can join (and leave) VOs at any time. Joining a VO is
> actually quite simple: usually each VO maintains a web page, where you
> authenticate with your X509 vertificate. You fill a form, and your
> request for membership is approved by the VO manager. Then, the VOMS
> server(s) are instructed to add the new VO membership information when
> you request a VOMS proxy with the voms-proxy-init command.
> This currently works quite well for gLite, and allows VO administrators
> to grand and revoke VO membership information without requesting users
> to ask for a new X509 certificate. This also allows Certification
> Authorities to be completely VO-agnostic (if a new VO is created, you
> don't need to tell the CAs to release attributes for the new VO as well).
>
> Moreno.
>
> --
> Moreno Marzolla
> INFN Sezione di Padova,    via Marzolo 8,   35131 PADOVA,  Italy
> EMail: moreno.marzolla at pd.infn.it         Phone: +39 049 8277047
> 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/20090323/92c071e6/attachment.html