- pgi-wg - lists.ogf.org

Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Howdy, >- I do code for doing authentication with and without proxies. And I never noticed significant difference. We do to - difference, for example, would be to climb the proxy chain using the "specific path validation algorithm" which is not needed by using typical X.509 certs. >- So why not to use last option? Or am I missing something? As I said before - probably not all services understand normal TLS and require proxies where pure PGI_TLS is not correct - e.g. CREAM-BES I know from my own experience so far. >- If (a) covers (b) then "either (a) or (b)" is not achievable. my fault - (a) should be rather in the questions section, but an answer from gLite may help to understand. 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(a)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: Aleksandr Konstantinov <aleksandr.konstantinov(a)fys.uio.no> Date: Friday, March 20, 2009 12:26 pm Subject: Re: [Pgi-wg]Sec: Agreement on attribute transport mechanisms forAttrAuthZ > On Friday 20 March 2009 12:08, Morris Riedel wrote: > > Good morning Aleksandr, > > > > > > >-I see no reason for "either". Also it would be nice to > define used > > terms. > > >-AFAIK there are no restrictions for using X.509 proxies (aka > PC) in TLS. > > As long as > > >-we are talking about > > >-standardaized PCs (RFC 3820) of course. > > >-For infrastructures relying on full or partial/restricted > X.509 identity > > delegation PC > > >-(proxy certificate) is > > >-a must. But I see no reason why that should exclude usage of > ordinary> X.509 > > >-certificates/keys as > > >-mean for identifying (direct or through attributes) > communicating parties. > > > > > > The reason is basically to precisely define what an endpoint > supports, if do > > not define this precisely interoperability will break since > there is a big > > difference using TLS with or without proxies for the authN > check. The either > > I do code for doing authentication with and without proxies. And I > never > noticed significant difference. > > > is a reason to make it more simpler although there is a polymorphic > > dependency, but this is not always helpful for the implementations. > > > > Example: > > > > (a) > > For instance, if we would only claim that the UNICORE Gateway > (AuthN check > > for end-users) supports the PGI_TLS w/o knowing if it uses > proxies or not: > > > > If you then use your ARC-Client with proxies and access the > Gateway you > > fail, because the AuthN check only checks for full end-entity > certificates.> > > (b) > > For instance, if we would claim that UNICORE Gateway supports > PGI_GSI (so > > proxies including some newly defined PGI revocation mechanism > since this is > > a general GSI problem, or proxy problem although they have > limited lifetime) > > : > > > > If you then use your ARC client with proxies and access the > Gateway you win, > > because the AuthN check climbs up the whole proxy-hierarchy. > > > > If we use our own UNICORE Client with full end-entity > certificates it works > > as well since PGI_GSI MAY include PGI_TLS (your polymorphic item). > > So why not to use last option? Or am I missing something? > > > > > ### Conclusions and motivation for either: > > > > (a) > > So clearly every service that do supports PGI_GSI is able to > accept client > > request based on PGI_TLS only > > > > (b) > > But every service that purely supports PGI_TLS is not able to > accept client > > requests based on PGI_GSI > > > > Bottom line: the either is needed for differentiation including > inherently> your statement of polymorphism that only indicated > 'one direction' or 'is-a' > > and not the other direction! > > If (a) covers (b) then "either (a) or (b)" is not achievable. > > > A.K. > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

1 0

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi, ok let's put it as follows: I meant "proxy-based TLS == GSI" - maybe a bit simplified but isn't it clear in the context here? But we can talk about GSI then... Yeah GridFTP is an important service but indeed with no WS-interface, so out of scope here. What do you think about the "either-or" dependency to nail it down more precisely. 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(a)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: weizhong qiang <weizhongqiang(a)gmail.com> Date: Thursday, March 19, 2009 3:51 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > hi, > I think the issue you proposed can be divided into branches (since > HTTPS is > actually http + tls/ssl): > 1. If all of the PGI services use SOAP (i.e. Web Service interface)? > 2. If all of the PGI services use TLS? > For the first one, at least GridFTP service is excluded, while it > is widely > used by production grid. > For the second, maybe most of the services are based on secure > transportcommunication, but some of them are using GSI (SRM > service: SOAP + GSI?) > > In terms of ARC, the A-REX service (for job management, supporting > BES,JSDL) is using SOAP plus TLS, while it is also configurable to > support SOAP > plus GSI. > > Regards, > Weizhong > > 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > > > Hi security folks, > > > > > > reading certain elements of the IIRM, strawman, and following > discussions> on the list - I see there is still no common > agreement on SOAP / HTTP(S) in > > some areas. > > > > ### Goal: > > > > (a) > > We are discussing if SOAP / HTTPS can be used in PGI to contact a > > functional > > interface (like BES)... > > > > (b) > > ...because we want to find out if there is any important service > in the PGI > > context that is not capable of using SOAP (over SSL layer)... > > > > > > (c) > > ... in order to find out if we can agree on SOAP/HTTPS or to > understand> requirements from other non WS-based interfaces in PGI. > > > > > > Therefore the aim of this thread is to get to an agreement in > this context, > > while considering Attribute authorities like VOMS as a > supportive service > > and not an functional interface (also separate thread). > > > > ### Contacting functional implementations with SOAP > > > > If we consider the case that we communicate with an functional > interface> like OGSA-BES - we agree on SOAP. > > > > ### TLS/SSL Layer: > > > > # <strawman> > > Foundational: Conveying identity for authentication. > > SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using > a SSL/TLS > > transport protocol in which endpoints are mutually authenticated > by X.509 > > end-entity public key certificates (PKCs). > > # </strawman> > > > > > > # <simple plumbings: authentication> > > We use authentication either based on identities inside X.509 > end-entity > > public key certificates or X.509 proxies (including > restrictions, encoding > > handled separately in another thread). > > > > This refers of using either one or the other of these > certificate types on > > the SSL/TLS level. > > > > For simplification of the profile - there should be no direct > dependencies> with attribute-transport used for authorization. > > # </plumbings> > > > > > > ### Possible scenarios: > > > > # A. TLS with end-entity certificate, SOAP in message -> authN > check with > > CA > > > > # B. TLS with (restricted) proxy certificates, SOAP in message - > > authN > > check with proxy signer chain > > > > ### Possible Conclusion: > > > > # We use SOAP inside a message to contact functional interfaces. > > > > # We use either full X.509 end-entity certificates OR X.509 > proxies (with > > restrictions) > > > > ### Open Questions: > > > > > > Q: There are WS interfaces for functional specifications that > matter to PGI > > (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree > on SOAP > > based on HTTPS as mentioned above? > > > > Q: If not - are there any important functional interfaces > (except support > > interfaces from AAs like classic VOMS) that do not support SOAP > in the PGI > > ecosystem? > > > > > > Please feel free to comment but let the question of > attributes+restrictions> outside - I propose to deal with it in > separate threads because of their > > complexity. > > > > > > 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(a)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) > > > > > > > > _______________________________________________ > > Pgi-wg mailing list > > Pgi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/pgi-wg > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

4 6

Sec: Agreement on WS-Naming (ref by strawman)
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi security folks, in preparation of tomorrow I scanned the WS-Naming spec (GFD109) since there was an optional (MAY) dependency in the strawman doc of it. ### Goal: (a) We are discussing the WS-Naming specification... (b) ... because we want to survey what's is adoption status is in production setups is and what impacts might occur when implementing it... (c) ... in order to find out if the WS-Naming dependency makes sense for PGI in general and for our security setup in particular. ### Bottom line of spec contents # Defines an Endpoint Identifier Profile -> WS-A add-ons # WS Address Endpoint identifier Profile -> WS-A add-ons # Endpoint Resolvers Profiles -> portType ### Possible Conclusions: # (A) As discussed earlier, this is yet another profile that increases the size of an EPR significantly -> while one spec adoption might not be critical, adopting WS-Naming together with OGF Sec Addressing and VO lists in WS-MetaData elements of EPRs might be together a 'just too big' EPR to be realistic - apart from the functionality of the necessary resolvers in particular for WS-Naming. Bottom line: Too much for the EPR - rather covered by an appropriate information service ### Questions: # (A) Which middleware platform is adopting it currently and has precise plans to adopt it in the near future. We can list for now GENESIS-II adopting it while I know that UNICORE does not and has no precise plans for it now - what about others like gLite, ARC, or NAREGI? # (B) Is GLUE covering partly the information of getting endpoints for unique names or something similiar like renewable references? The discussion before the TelCon might increase our progress... Your co-chair, 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(a)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.' ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

5 5

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Duane, in addition I forgot to mention that we already agreed in PGI that we only do attribute-based authorization for those that would like to be PGI-compliant while still supporting identity-based authZ of course. It's not related here for AuthN - but helps to understand my circumvention of the complicated 'additional' scope. It makes sense - but allows too much flexibility I think that break possibly interop again. You may want to support still purely identity-based authZ in the non-PGI-compliant part. At least that is my suggestion. Otherwise we end up of standardizing each functionality purely out of our systems. Sorry for not mention that again, 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(a)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: Duane Merrill <dgm4d(a)virginia.edu> Date: Thursday, March 19, 2009 2:40 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > I don't understand the strict "either-or" wording below with > regards to PCs > versus PKCs in a *proxy-plus-embedded-AC* conformance target. You > make it > sound like their use would be unilaterally mutually exclusive. > Both types > of certificates can embed attribute certificates, and there is an > "is-a"/polymorphic relationship here: a PKC is a PC of delegation > depth zero > (and therefore does not have the extension OID set). > > A *proxy-plus-embedded-AC* conformance target should describe > implementations that allow both. In the strawman document, the > goal of > layering the *pgi-tls-proxy* conformance target on top of the > *pgi-https*target was to add functionality (not take it away): > *pgi-tls-proxy* describes SOAP implementations that perform mutual > SSL/TLSauthentication with certificates, and these certificates > MAY have proxy > extensions (making them PCs) and MAY have AC extensions (embedding > attributecertificates). > > Perhaps I am just misinterpreting your language. > > -Duane > > 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > > > Hi security folks, > > > > > > reading certain elements of the IIRM, strawman, and following > discussions> on the list - I see there is still no common > agreement on SOAP / HTTP(S) in > > some areas. > > > > ### Goal: > > > > (a) > > We are discussing if SOAP / HTTPS can be used in PGI to contact a > > functional > > interface (like BES)... > > > > (b) > > ...because we want to find out if there is any important service > in the PGI > > context that is not capable of using SOAP (over SSL layer)... > > > > > > (c) > > ... in order to find out if we can agree on SOAP/HTTPS or to > understand> requirements from other non WS-based interfaces in PGI. > > > > > > Therefore the aim of this thread is to get to an agreement in > this context, > > while considering Attribute authorities like VOMS as a > supportive service > > and not an functional interface (also separate thread). > > > > ### Contacting functional implementations with SOAP > > > > If we consider the case that we communicate with an functional > interface> like OGSA-BES - we agree on SOAP. > > > > ### TLS/SSL Layer: > > > > # <strawman> > > Foundational: Conveying identity for authentication. > > SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using > a SSL/TLS > > transport protocol in which endpoints are mutually authenticated > by X.509 > > end-entity public key certificates (PKCs). > > # </strawman> > > > > > > # <simple plumbings: authentication> > > We use authentication either based on identities inside X.509 > end-entity > > public key certificates or X.509 proxies (including > restrictions, encoding > > handled separately in another thread). > > > > This refers of using either one or the other of these > certificate types on > > the SSL/TLS level. > > > > For simplification of the profile - there should be no direct > dependencies> with attribute-transport used for authorization. > > # </plumbings> > > > > > > ### Possible scenarios: > > > > # A. TLS with end-entity certificate, SOAP in message -> authN > check with > > CA > > > > # B. TLS with (restricted) proxy certificates, SOAP in message - > > authN > > check with proxy signer chain > > > > ### Possible Conclusion: > > > > # We use SOAP inside a message to contact functional interfaces. > > > > # We use either full X.509 end-entity certificates OR X.509 > proxies (with > > restrictions) > > > > ### Open Questions: > > > > > > Q: There are WS interfaces for functional specifications that > matter to PGI > > (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree > on SOAP > > based on HTTPS as mentioned above? > > > > Q: If not - are there any important functional interfaces > (except support > > interfaces from AAs like classic VOMS) that do not support SOAP > in the PGI > > ecosystem? > > > > > > Please feel free to comment but let the question of > attributes+restrictions> outside - I propose to deal with it in > separate threads because of their > > complexity. > > > > > > 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(a)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) > > > > > > > > _______________________________________________ > > Pgi-wg mailing list > > Pgi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/pgi-wg > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ
by Aleksandr Konstantinov 20 Mar '09

20 Mar '09

On Friday 20 March 2009 13:14, Morris Riedel wrote: > Hi, > > > > >- My personal thinking is, since we are talking about PGI or > interoperability, we probably do need to change the current implementation > if it can not satisfy interoperability, while keeping the principle that the > change should be as little as possible. > > > > In terms of little changes I agree - but I consider PGI_TLS / PGI_GSI as > massive changes. > > > > For instance, we have developed a UNICORE Gateway (for AuthN) that works > with PGI_TLS naturally - and PGI_GSI more recently providing of course not > FULL delegation support per hop, but proxies are supported on GSI-TLS level. I'm lost. What do mean by PGI_GSI technically? Is there any document which defines it? How is it related to delegation? A.K.

1 0

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi Duane, have you read the slides about the IIRM and the plumbings concept was basically refers to that concept of "either-or". Although both are X.509 certificates - It's a fundamental difference if you have full X.509 end-entity certificates only signes by a CA you trust or X.509 certificates signed by users with a chain. Implementations have to now the difference in order to 'climb the whole chain' while doing authentication - that was breaking interoperability in the past between numerous implementatio. In short: my suggestion is to remove too much flexibility by just using "either or" for these models that are quite established. Furthermore, I would like to decouple the attrauthZ from TLS. I hope it gets a bit clearer now - but I feel the need for a picture, I start to develop a small supportive figure here. 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(a)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: Duane Merrill <dgm4d(a)virginia.edu> Date: Thursday, March 19, 2009 2:40 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > I don't understand the strict "either-or" wording below with > regards to PCs > versus PKCs in a *proxy-plus-embedded-AC* conformance target. You > make it > sound like their use would be unilaterally mutually exclusive. > Both types > of certificates can embed attribute certificates, and there is an > "is-a"/polymorphic relationship here: a PKC is a PC of delegation > depth zero > (and therefore does not have the extension OID set). > > A *proxy-plus-embedded-AC* conformance target should describe > implementations that allow both. In the strawman document, the > goal of > layering the *pgi-tls-proxy* conformance target on top of the > *pgi-https*target was to add functionality (not take it away): > *pgi-tls-proxy* describes SOAP implementations that perform mutual > SSL/TLSauthentication with certificates, and these certificates > MAY have proxy > extensions (making them PCs) and MAY have AC extensions (embedding > attributecertificates). > > Perhaps I am just misinterpreting your language. > > -Duane > > 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > > > Hi security folks, > > > > > > reading certain elements of the IIRM, strawman, and following > discussions> on the list - I see there is still no common > agreement on SOAP / HTTP(S) in > > some areas. > > > > ### Goal: > > > > (a) > > We are discussing if SOAP / HTTPS can be used in PGI to contact a > > functional > > interface (like BES)... > > > > (b) > > ...because we want to find out if there is any important service > in the PGI > > context that is not capable of using SOAP (over SSL layer)... > > > > > > (c) > > ... in order to find out if we can agree on SOAP/HTTPS or to > understand> requirements from other non WS-based interfaces in PGI. > > > > > > Therefore the aim of this thread is to get to an agreement in > this context, > > while considering Attribute authorities like VOMS as a > supportive service > > and not an functional interface (also separate thread). > > > > ### Contacting functional implementations with SOAP > > > > If we consider the case that we communicate with an functional > interface> like OGSA-BES - we agree on SOAP. > > > > ### TLS/SSL Layer: > > > > # <strawman> > > Foundational: Conveying identity for authentication. > > SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using > a SSL/TLS > > transport protocol in which endpoints are mutually authenticated > by X.509 > > end-entity public key certificates (PKCs). > > # </strawman> > > > > > > # <simple plumbings: authentication> > > We use authentication either based on identities inside X.509 > end-entity > > public key certificates or X.509 proxies (including > restrictions, encoding > > handled separately in another thread). > > > > This refers of using either one or the other of these > certificate types on > > the SSL/TLS level. > > > > For simplification of the profile - there should be no direct > dependencies> with attribute-transport used for authorization. > > # </plumbings> > > > > > > ### Possible scenarios: > > > > # A. TLS with end-entity certificate, SOAP in message -> authN > check with > > CA > > > > # B. TLS with (restricted) proxy certificates, SOAP in message - > > authN > > check with proxy signer chain > > > > ### Possible Conclusion: > > > > # We use SOAP inside a message to contact functional interfaces. > > > > # We use either full X.509 end-entity certificates OR X.509 > proxies (with > > restrictions) > > > > ### Open Questions: > > > > > > Q: There are WS interfaces for functional specifications that > matter to PGI > > (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree > on SOAP > > based on HTTPS as mentioned above? > > > > Q: If not - are there any important functional interfaces > (except support > > interfaces from AAs like classic VOMS) that do not support SOAP > in the PGI > > ecosystem? > > > > > > Please feel free to comment but let the question of > attributes+restrictions> outside - I propose to deal with it in > separate threads because of their > > complexity. > > > > > > 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(a)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) > > > > > > > > _______________________________________________ > > Pgi-wg mailing list > > Pgi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/pgi-wg > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ
by Moreno Marzolla 20 Mar '09

20 Mar '09

Morris Riedel wrote: [...] > Q: Do gLite also supports pure PGI_TLS apart from PGI_GSI? 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. Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla(a)pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233

1 0

Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ
by weizhong qiang 20 Mar '09

20 Mar '09

hi, PGI_TLS and PGI_GSI were mentioned by you in a few thread. Again, I would like clarify something from my point of view. Do you mean PGI_GSI the services/clients that talk to each other by using GSSAPI? or just talk to each other based on TLS while using proxy certificate. I think there is difference between them. So I would divide them into branch by using your notation: PGI_TLS PGI_TLS_PROXY (the notation is also in the virginia strawman) PGI_GSI 2009/3/20 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi, > > > > >- My personal thinking is, since we are talking about PGI or > interoperability, we probably do need to change the current implementation > if it can not satisfy interoperability, while keeping the principle that the > change should be as little as possible. > > > > In terms of little changes I agree – but I consider PGI_TLS / PGI_GSI as > massive changes. > > > > For instance, we have developed a UNICORE Gateway (for AuthN) that works > with PGI_TLS naturally – and PGI_GSI more recently providing of course not > FULL delegation support per hop, but proxies are supported on GSI-TLS level. > > > > > > However, can we expect that you one contact a CREAM-BES any time soon with > full end-entity credentials or any other gLite component? > The CREAM service has been tested (by some of our colleagues) . And the result shows CREAM service requires "limited" proxy certificate (proxy with "CN=proxy") when it doing data transfer. Inherently, because of forwarding mechanisms internally – proxies are > necessary probably. > > > > But maybe that’s my old interop* knowledge – so let’s clarify again… > > > > Some statements that need clarification: > > > > Note: UNICORE can be contacted using PGI_TLS and PGI_GSI – the same is > planned for GENESIS-II as far as I remember. > "and PGI_GSI" means PGI_TLS_PROXY or PGI_GSI? >From out experience about testing against UNICORE service, it uses PGI_TLS_PROXY. > > > > Q: Do gLite also supports pure PGI_TLS apart from PGI_GSI? > > > > > > Q: Do ARC also supports pure PGI_TLS apart from PGI_GSI? > PGI_TLS PGI_TLS_PROXY possible to support PGI_GSI (the definition I mentioned) > > > > > Q: Do we really imply that PGI-compliance means that both PGI_GSI and pure > PGI_TLS have to be supported? Or we rather go the plumbing way of defining > either or as MANDATORY and as MAY both supported (two plumbings). > I see PGI_TLS_PROXY should be mandatory. Regards, Weizhong > > Thanks for clarification, > > Morris > > > > > > *From:* Steven Newhouse [mailto:Steven.Newhouse@cern.ch] > *Sent:* Friday, March 20, 2009 11:49 AM > *To:* weizhong qiang; Morris Riedel > *Cc:* pgi-wg(a)ogf.org > *Subject:* RE: [Pgi-wg] Sec: Agreement on attribute transport > mechanismsforAttrAuthZ > > > > My personal thinking is, since we are talking about PGI or > interoperability, we probably do need to change the current implementation > if it can not satisfy interoperability, while keeping the principle that the > change should be as little as possible. > > > > And to clearly describe the interoperability benefits that will be derived > (i.e. systems and communities) by making that change. > > > > Steven > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

1 0

Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
by Aleksandr Konstantinov 20 Mar '09

20 Mar '09

On Friday 20 March 2009 12:24, Morris Riedel wrote: > Hi, > > >- As I > >-explained in an earlier mail, "limited" here means that the PGI profile > >-shall precisely described in a self-contained way the minimum set of EPR > >-elements which must be supported by conforming inplementations. > > So far, I guess we only depend on the wsa:To element of the specification > with the URI making it the minimum element of it. > > With WS-Naming this would be expanded using wsa:metadata and ws-naming > elements of course. > > Isn't our usual procedure to take the URI - encode an EPR (with wsa:To) and > send it to the BES systems? Or is this maybe only my narrow UNICORE view of > how we do it? > > Q: What is meant by accessing a CREAM-BES and A-REX with URI (instead of > EPRs)? ARC does not rely on EPR present in SOAP messages header sent to BES service. ARC clients do put EPRs into headers for compatibility. Hosting environment of ARC services may perform routing of messages depending on wsa:To element of EPR. To make it short - we can live with and without EPRs. AFAIR BES specs say nothing about if BES service has to be contacted using EPRs. A.K.

1 0

Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
by Aleksandr Konstantinov 20 Mar '09

20 Mar '09

On Friday 20 March 2009 12:21, Morris Riedel wrote: > Hi Aleksandr, > > >-IMO the real question is what such EPRs may be used for. If they planned > as > >-replacements for URLs and *full* such EPR is going to be put into > >-every SOAP header then I wohuld vote strongly against. But if such EPR is > just a way > >-to describe service (same as corresponding section in Glue > >-document) and are ony meant to be used in some kind of information > system/port > >-then why not. > > Just for clarification: With URLs you refer to the wsa:To element of > WS-Addressing correct? If so, they are of course in any SOAP message - or I > didn't get your point. With URL I mean URL which was supposed to identify resource. Now with introduction of EPRs we get another layer of indirection in resource identification. That's alright. But EPRs can also be used to describe resource. And that description part may become lenghty. So if PGI goes for EPR I would like to see it profiled which parts of EPR are expected/needed at which place/moment. If my client application queries for some service with specific capabilities and gets 100kB EPR describing who where and how can contact service that is probably ok. But if for contacting that service my application has to insert that EPR into every SOAP message I would like to know which parts of it I can be safely removed in order to avoid buying dedicated optical link to computing center hosting that service. :) > > Also, if it would be only to put into a kind of information system I would > vote for crunching the EPR in elements that can be probably better searched > for by an query instead of putting information into EPR. I just have to agree. > > Here, WS-Naming, provides basically a name of a service while its EPR might > change over time (renewable reference). Also the document refers to > trackability of messages once you use WS-Naming (e.g. UUID dependency) - so > I expect that this information of WS-Naming EPR additions should be part of > any SOAP message. But that's only my interpretation from the document. > > > Q: Can we agree that each functional service in the EPR space such as > OGSA-BES are contacted with an pure EPR using URIs? We don't consider > accessing a BESService simply with an URI - or do we? I would not vote for > that. I would like to know what do You mean by "contacted". If that implies human user is expected to write EPR by hand to make his/her client to contact some service then I disagree. A.K.

1 0