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