Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ
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?! 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? 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 ------------------------------------------------------------------- -------------------------------------------------------------------
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 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
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
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. 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
participants (4)
-
Aleksandr Konstantinov -
m.riedel＠fz-juelich.de -
Moreno Marzolla -
Morris Riedel