[Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ

Fri Mar 27 07:35:22 CDT 2009

On Friday 27 March 2009 11:28, you wrote:
> Hi,
> 
> >- Of course. "Full certificate" is just an extreme case of proxy
> certificate - like table without legs.
> 
> Unfortunately, we heard earlier that this is not generally the case since
> GSI proxy-based TLS changes also the wire or handshaking process while I
> agree with end-entity TLS is a subset (as chain length 0 proxy) of normal
> TLS.

We are talking of different things. AGAIN.

A.K.

> 
> However, in practical works I have done in scenarios - I learned we have to
> support both. So I see that we have to support both?!
> 
> Take care,
> Morris
> 
> ------------------------------------------------------------
> Morris Riedel
> SW - Engineer
> Distributed Systems and Grid Computing Division
> Jülich Supercomputing Centre (JSC)
> Forschungszentrum Juelich
> Wilhelm-Johnen-Str. 1
> D - 52425 Juelich
> Germany
> 
> Email: m.riedel at fz-juelich.de
> Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel
> Phone: +49 2461 61 - 3651
> Fax: +49 2461 61 - 6656
> 
> Skype: MorrisRiedel
> 
> "We work to better ourselves, and the rest of humanity"
> 
> Sitz der Gesellschaft: Jülich
> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
> Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), 
> Dr. Ulrich Krafft (stellv. Vorsitzender)
> 
> 
> >------Original Message-----
> >-From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of
> >-Aleksandr Konstantinov
> >-Sent: Friday, March 27, 2009 9:26 AM
> >-To: pgi-wg at ogf.org
> >-Subject: Re: [Pgi-wg]Sec: Agreement on
> attributetransportmechanismsforAttrAuthZ
> >-
> >-On Friday 20 March 2009 16:35, 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 would say it is not needed from service point of view. It is just
> supported.
> >-But it is needed from another service point of view, which for example
> submits job to
> >-BES on behalf of original user.
> >-If that "on behalf" thing is implemented using proxy delegation, then
> starting from
> >-second service in a chain all services
> >-must accept proxies.
> >-Of course all services (except last one) also must provide way to accept
> delegated
> >-credentials. But that is probably out
> >-of topic for this discussion.
> >-Of course there are other ways to implement "on behalf", and SAML is one
> of them.
> >-
> >->
> >-> Q: It looks like now all middlewares can be accessed then easily with
> using full
> >-end-entity certificates: UNICORE, GENESIS-II, gLite,.. What about ARC?
> >-
> >-Of course. "Full certificate" is just an extreme case of proxy certificate
> - like table
> >-without legs.
> >-
> >-A.K.
> >-
> >-
> >-> Thanks for pointing this out Moreno - indeed helpful - I missed that new
> fact.
> >->
> >-> 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:25 pm
> >-> Subject: Re: [Pgi-wg] Sec: Agreement	on	attribute
> >-transportmechanismsforAttrAuthZ
> >->
> >-> > m.riedel at fz-juelich.de wrote:
> >-> > > Hi,
> >-> > >
> >-> > >> -  The gLite CREAM CE can be accessed either with pure TLS (X509
> >-> > > certificate) or using GSI (proxy-based) authentication. I think that
> >-> > > the same holds for other gLite components as well.
> >-> > >
> >-> > >
> >-> > > So your service can work w/o proxies? Maybe for the initial
> >-> > AuthN yes
> >-> > > - but for further use I guess you require a proxy for forwarding to
> >-> > > CREAM or so?!
> >-> >
> >-> > You can invoke any CREAM operation using either a plain X509
> >-> > certificate, or a proxy certificate. In either case you can use
> >-> > the
> >-> > service without problems. HOWEVER, in order to submit a job you
> >-> > NEED to
> >-> > delegate a proxy to CREAM by first invoking the delegation port-
> >-> > type.
> >-> > Once you have delegated a proxy, you can create/cancel/monitor
> >-> > your jobs
> >-> > with plain X509 certificates.
> >-> >
> >-> > Note that in order to contact the delegation port-type you can use
> >-> > either an X509 certificate, or a proxy certificate.
> >-> >
> >-> > So, a client with *only* an X509 certificate can perform any
> >-> > operation
> >-> > on CREAM, PROVIDED that FIRST it delegates its credential to CREAM
> >-> > by
> >-> > performing a delegation operation. A client with a delegated proxy
> >-> > can
> >-> > also execute any operation on CREAM, provided that it further
> >-> > delegates
> >-> > its credentials to CREAM.
> >-> >
> >-> > 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.
> >-> >
> >-> > 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
> >-> -------------------------------------------------------------------
> >-> -------------------------------------------------------------------
> >-> _______________________________________________
> >-> Pgi-wg mailing list
> >-> Pgi-wg at ogf.org
> >-> http://www.ogf.org/mailman/listinfo/pgi-wg
> >->
> >-_______________________________________________
> >-Pgi-wg mailing list
> >-Pgi-wg at ogf.org
> >-http://www.ogf.org/mailman/listinfo/pgi-wg
> 