Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ
hi, can you not just use the full end-entity certs with extensions (i.e. put ACs there=? Take care, Morris -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ----- Original Message ----- From: Moreno Marzolla <moreno.marzolla@pd.infn.it> Date: Friday, March 20, 2009 3:55 pm Subject: Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ
Hi,
- This is the problem you mentioned which we experienced during
m.riedel@fz-juelich.de wrote: the
OMII-EU project: BES clients were not executing the delegation operation, so the service did not have any delegated credentials to use. We then implemented a horrible workaround in CREAM which was fine for demonstration purposes, but unfortunately can not be applied for any real use.
ok, that's interesting - if you don't extract the proxy obviously then from TLS level during AuthN steps - why is there still a proxy support needed on the TLS level then?!
I answer your question according to the understanding I just gained from our security experts, so bear with me :-) The gLite middleware relies on VOMS extensions to associate roles to users according to the VO they belong to. If you use plain X509 certificates, of course you don't have any VO information there, so it is not possible for services to assign roles to the bearer of those certificates. Suppose you want to submit a job to CREAM, and the job needs to stage external data to/from a service which DOES require VO extensions in order to perform authorization decisions. In this situation you need at least to delegate to CREAM a certificate with VOMS extensions (the delegated certificate will be used by CREAM to access external resources on behalf of the user). Of course, if you have an X509 certificate signed by a "conventional" certification authority, you cannot stick VOMS extensions inside it. For this reasons, when gLite users want to interact with CREAM directly, they first create a VOMS proxy certificate via the voms-proxy-init command. Thus, using a proxy to interact with CREAM is only needed to have VOMS extensions inside the credential used to interact with the service. If your job does not require to access any external service, OR if that external service does not rely on VOMS extensions, then you are perfectly fine using plain X509 certificates only.
Moreno.
-- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------
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.). In this case, the callee services wouldbe advertised in EPRs as being pgi-proxy-ac-tls compliant. Duane On 3/20/09, m.riedel@fz-juelich.de <m.riedel@fz-juelich.de> wrote:
hi,
can you not just use the full end-entity certs with extensions (i.e. put ACs there=?
Take care, Morris
-------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany
Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel
Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656
Skype: MorrisRiedel
'We work to improve ourselves and the rest of mankind.'
----- Original Message ----- From: Moreno Marzolla <moreno.marzolla@pd.infn.it> Date: Friday, March 20, 2009 3:55 pm Subject: Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ
Hi,
- This is the problem you mentioned which we experienced during
m.riedel@fz-juelich.de wrote: the
OMII-EU project: BES clients were not executing the delegation operation, so the service did not have any delegated credentials to use. We then implemented a horrible workaround in CREAM which was fine for demonstration purposes, but unfortunately can not be applied for any real use.
ok, that's interesting - if you don't extract the proxy obviously then from TLS level during AuthN steps - why is there still a proxy support needed on the TLS level then?!
I answer your question according to the understanding I just gained from our security experts, so bear with me :-) The gLite middleware relies on VOMS extensions to associate roles to users according to the VO they belong to. If you use plain X509 certificates, of course you don't have any VO information there, so it is not possible for services to assign roles to the bearer of those certificates. Suppose you want to submit a job to CREAM, and the job needs to stage external data to/from a service which DOES require VO extensions in order to perform authorization decisions. In this situation you need at least to delegate to CREAM a certificate with VOMS extensions (the delegated certificate will be used by CREAM to access external resources on behalf of the user). Of course, if you have an X509 certificate signed by a "conventional" certification authority, you cannot stick VOMS extensions inside it. For this reasons, when gLite users want to interact with CREAM directly, they first create a VOMS proxy certificate via the voms-proxy-init command. Thus, using a proxy to interact with CREAM is only needed to have VOMS extensions inside the credential used to interact with the service. If your job does not require to access any external service, OR if that external service does not rely on VOMS extensions, then you are perfectly fine using plain X509 certificates only.
Moreno.
-- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich
Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- ------------------------------------------------------------------- _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
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@pd.infn.it Phone: +39 049 8277047 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
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@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@pd.infn.it Phone: +39 049 8277047 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233
On Mon, Mar 23, 2009 at 11:47 AM, Duane Merrill <dgm4d@virginia.edu> wrote:
..but would be unable to sign them with anything other than a proxy-certificate ...
I mean "unable to sign the message with anything other than a proxy-certificate".
participants (3)
-
Duane Merrill -
m.riedel＠fz-juelich.de -
Moreno Marzolla