[Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ

[m.riedel at fz-juelich.de]

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 at 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 at pd.infn.it>
Date: Friday, March 20, 2009 3:55 pm
Subject: Re: [Pgi-wg] Sec:	Agreement	on	attributetransportmechanismsforAttrAuthZ

> m.riedel at fz-juelich.de wrote:
> > Hi,
> > 
> >> - This is the problem you mentioned which we experienced during 
> 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 at 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
-------------------------------------------------------------------
-------------------------------------------------------------------