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:
- 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)
- 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
> 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
>
>