27 Mar
2009
27 Mar
'09
12:35 p.m.
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@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@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of > >-Aleksandr Konstantinov > >-Sent: Friday, March 27, 2009 9:26 AM > >-To: pgi-wg@ogf.org > >-Subject: Re: [Pgi-wg]Sec: Agreement on > attributetransportmechanismsforAttrAuthZ > >- > >-On Friday 20 March 2009 16:35, m.riedel@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@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:25 pm > >-> Subject: Re: [Pgi-wg] Sec: Agreement on attribute > >-transportmechanismsforAttrAuthZ > >-> > >-> > m.riedel@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@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 > >-> > >-_______________________________________________ > >-Pgi-wg mailing list > >-Pgi-wg@ogf.org > >-http://www.ogf.org/mailman/listinfo/pgi-wg >