- pgi-wg - lists.ogf.org

PGI Meeting Minutes Location
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi folks, I just get questions regarding the minutes location. Please note that the minutes of each TelCon (+ OGF sessions) are in the gridforge 'discussion' section: http://forge.gridforum.org/sf/discussion/do/listTopics/projects.pgi-wg/disc… Hear you soon, 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: m.riedel(a)fz-juelich.de Date: Friday, March 20, 2009 3:46 pm Subject: Re: [Pgi-wg] Sec: Agreement onattributetransportmechanismsforAttrAuthZ > Hi, > > >- What is for sure is that you can not use client based on normal > TLS to talk with service which is based on GSSAPI, or vice versa. > > I made this experience as well - but a few month ago... > > Maybe things have been changed like within gLite then? > > 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: Friday, March 20, 2009 3:41 pm > Subject: Re: [Pgi-wg] Sec: Agreement on attribute > transportmechanismsforAttrAuthZ > > On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel(a)fz-juelich.de> wrote: > > > > > Howdy, > > > > > > >-PGI_TLS_PROXY (the notation is also in the virginia strawman) > > > >-PGI_GSI > > > > > > so in this context what is the difference on TLS itself w/o > > considering> different APIs?! > > > > > > > Basically the globus implementation if GSSAPI is about a specific > > context-initiation negotiation, and some data-padding for > > initiation and > > data-transferring. Also you can accomplish proxy-delegation via it. > > What is for sure is that you can not use client based on normal > > TLS to talk > > with service which is based on GSSAPI, or vice versa. > > AFAIK, There is some grid service (WS compliant) such as some > SRM > > servicewhich uses GSSAPI. (SOAP + HTTP + GSS). > > > > > > Weizhong > > > > > > > > > > Good point in checking this out - I'm still think its rather > > the same. > > > > > > Thanks for clarification, > > > Morris > > > > > > > > > > > > > > > ------------------------------------------------------------------- > ------------------------------------------------------------------- > 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(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, >- Proxy certs require *additional* path validation. Exactly, that's where it is all about - I think we still misunderstand each other. In using your e-mail I try: Before I send someone an attach - I would like to know if the person has an email system with or w/o attachments ;-) That's my point - but let's discuss in the telcon about it. We are not talking about the same things. 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: Friday, March 20, 2009 1:52 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > I strongly disagree. > > Proxy certs require *additional* path validation. You *still* > have to do > the same PKC path validation on the EEC that the proxies chain to. > This > work has to be done regardless of whether there are proxy > certificates in > the chain. This is a clear "is-a" relationship, a superset of > functionalitywith PCs. > > Let me illustrate with an analogy: You are tasked to provide > requirementsfor an email system. What you are suggesting is > analagous to a requirement > that > > "The email system must EITHER support email-without-attachments OR > email-with-attachments." > > My point is that if you build an email system to support > email-with-attachments you have implicitly already built a system > to support > email-without-attachments. > > If you make it a requirement to reject PKCs explicitly, you are > creatingunnecessary additional complexity in both your services > (by explicitly > rejecting certs that do not have the proxy extension) and in your > clients(by mandating that callers with statically-assigned > credentials create a > proxy to delegate to themselves just so they can use your service). > > -Duane > > > > On Thu, Mar 19, 2009 at 1:20 PM, <m.riedel(a)fz-juelich.de> wrote: > > > 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 > > ----------------------------------------------------------------- > -- > > ----------------------------------------------------------------- > -- > > > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- 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] Discussion about elements/priorities in the field of security
by weizhong qiang 20 Mar '09

20 Mar '09

hi, Thanks for throwing out those points. 2009/3/17 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi PGI security folks, > > > currently I see five major elements in terms of security related to PGI: > > > (1) > Authentication/Attribute-based Authorization (i.e. plumbings as named > earlier), maybe first push-based before looking at pull-based models - > although, this of course, can be discussed as well among us. If we are talking about attributes carried inside SAML assetion, getting the attributes from attribute authority is not a challenge, for instance we can use the VOMS SAML service (client gets back SAML assertion that including attributes through SSL authentication with VOMS SAML service) as a candidate. But how to push the SAML assertion from client side to service side could be a challenge (for which voms has not provided solution, IMO). I can see two ways: one ways is put the SAML assertion into X.509 proxy certificate's extension, by which you can gurantee that the attributes information is binded with SSL authentication; the other way is to put SAML assertion in the SOAP header, which furtherly cause two branches: First brach, using the SAML assertion for message (SOAP) level authentication + attribute carraying (in this case the VOMS SAML service should probably be improved to creat SAML response containing a holder-of-key authentication assertion, then this assertion can be used for message level authentication according to WS-Security SAML Token profile 1.1); Second branch, using SAML assetion only for attribute carraying (in this case, the transport level securiry should be configured). I heard that VOMS attribute service is used in UNICORE, could some collegues provide some details about how the above scenario is processed? In case of ARC, it can get back SAML assertion from VOMS SAML service, and it can put the SAML assertion as extension of proxy certificate; It also support WS-Security (SAML Token profile, as well as UsernameToken and X.509 Token), but how to getting a SAMLToken is lacked. Maybe people from OGSA-AuthZ group can give some suggestions. > > > > (2) > Agreement on Definition/Semantics/Structure of Attributes Has the usage of SAML attribute assertion been decided? > > > > (3) > Encoding of delegation restriction/constraints The restriction is about what kind of policy will be used? > > > > (4) > Interface of delegation service (maybe based on subset of WS-Trust) > > > > (5) > Agreement on third party credentials transportation (e.g. a delegated > GridFTP proxy/SAML assertion-based access for data-staging during BES > submissions) > > > As a starting point - have I forgot something in this enumeration? If so - > please answer to this thread. > > > In terms of priorities, I would suggest to focus first on number one, but > of > course feel free to comment within this thread. Agree, IMO, the whole profile which will be adopted is mostly important. Regards, Weizhong > > > > Your co-chair, > Morris > > P.S. I cc'ed the area director of security (David Groep) to ensure that we > did not duplicate efforts done elsewhere (i.e. in the OGSA-AuthZ group). We > have been in touch about a few security issues raised in GIN earlier. CIAO. > > > ------------------------------------------------------------ > 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 > >

2 3

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

20 Mar '09

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?! In other words, if someone access your service with a proxy he is authenticated but can't work with the service since its requiring proxies?! Then, if not presented at TLS level, where do you get the proxy from? 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: Moreno Marzolla <moreno.marzolla(a)pd.infn.it> Date: Friday, March 20, 2009 1:24 pm Subject: Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ > 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 > > ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

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

20 Mar '09

YES! >- As Weizhong mentions, there are additional validation steps in the event that GSI detects the presence of a proxy-extension within a certficate during handshake. But nothing that affects wire protocol. And exactly because of this fact we have to indicate which services have to take these validation steps and which not. Q: The question is thus how you indicate within the PGI profiles that you support proxies or only full certificates (w/o additional validation steps). We getting closer... 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.' Content-Type: multipart/alternative; boundary=00163646c4b66c64ef04658ce960 --00163646c4b66c64ef04658ce960 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > > I think Weizhong means implmentation of GSIAPI like one from Globus which > does have > own communication protocol incompatible with TLS. > I don't believe there are any protocol changes between the secure-communication in GSI-API (GSI-OpenSSL) and TLS. As Weizhong mentions, there are additional validation steps in the event that GSI detects the presence of a proxy-extension within a certficate during handshake. But nothing that affects wire protocol. -Duane --00163646c4b66c64ef04658ce960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> <div class=3D"im">=A0</div>I think Weizhong means implmentation of GSIAPI l= ike one from Globus which does have<br>own communication protocol incompati= ble with TLS.<br><font color=3D"#888888"></font></blockquote> <div>=A0</div> <div>=A0</div> <div>=A0</div> <div>I don't believe there are any protocol changes between the secure-= communication in GSI-API (GSI-OpenSSL) and TLS.=A0 </div> <div>=A0</div> <div>As Weizhong mentions, there are additional validation steps in the eve= nt that GSI detects the presence of a proxy-extension within a certficate d= uring handshake.=A0 But nothing that affects wire protocol.</div> <div>=A0</div> <div>-Duane</div></div> --00163646c4b66c64ef04658ce960-- ------------------------------------------------------------------- ------------------------------------------------------------------- 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(a)ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg

1 0

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

20 Mar '09

Hi, >- I think Weizhong means implmentation of GSIAPI like one from Globus which does have >- own communication protocol incompatible with TLS. And I guess this is where all the misunderstandings comming from related to PGI_GSI or 'proxy-based TLS' :-) 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 2:22 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > On Friday 20 March 2009 15:14, Duane Merrill wrote: > > Embedded comments.... > > > > 2009/3/19 weizhong qiang <weizhongqiang(a)gmail.com> > > > > > > > > > > > On Thu, Mar 19, 2009 at 6:27 PM, <m.riedel(a)fz-juelich.de> wrote: > > > > > >> Hi, > > >> > > >> ok let's put it as follows: I meant "proxy-based TLS == GSI" > - > > > > > > > > > "proxy-based TLS" could also be normal TLS (only difference it > that you > > > need to check the delegation chain when verifying; the newer > version of > > > openssl itself has supported this, or you can also customize > the verifying > > > process of openssl with older version to support verification > of delegation > > > chain). > > > > > > > Correct. > > > > > > > > > > Of cause GSI is also "proxy-based TLS". But I thinks it is not > compatible> > to normal TLS since it use GSIAPI which has some > specific protocol. > > > > > > > > > I believe GSI-API is just that, a programming API that conforms > to RFC > > 2744<" target="l">http://www.faqs.org/rfcs/rfc2744.html> (GSS), > > and has no protocol restrictions/changes. > > I think Weizhong means implmentation of GSIAPI like one from > Globus which does have > own communication protocol incompatible with TLS. > > > 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

...we are not on the same page, let's wait for the telcon. -------------------------------------------------------------------------------- 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: Friday, March 20, 2009 2:09 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > Authorization *policy *is out of scope for this conversation. How > a callee > decides to perform allow/deny checks is irrelevent in a push-style > model. > I strongly suggest that we take a "zero-or-more" approach to both: > > - Proxy chain depth > - Attribute certificates > > You are suggesting a "one-or-more" approach, which is a Bad Idea > because it > increases complexity while reducing the number of supportable use- > cases.There is nothing good about a one-or-more mandate for either. > > -Duane > > > > On Thu, Mar 19, 2009 at 1:40 PM, <m.riedel(a)fz-juelich.de> wrote: > > > 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 > > ----------------------------------------------------------------- > -- > > ----------------------------------------------------------------- > -- > > > > > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

1 0

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

20 Mar '09

Hi, as mentioned before we have PGI_GSI as the elements of GSI related to TLS. We indicated in an earlier message that PGI_GSI is like "proxy-based TLS", but in the meanwhile even this has been revoked. Currently, I think each middleware representative is talking about different things. That's fun - but hard to get agreements! ;-) 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 2:04 pm Subject: Re: [Pgi-wg]Sec: Agreement on attribute transport mechanismsforAttrAuthZ > 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. > _______________________________________________ > 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

Subject indicates : we are at authentication - so let's keep to GSI in the context of TLS - Thanks -------------------------------------------------------------------------------- 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: Friday, March 20, 2009 2:01 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication > GSI encompasses MyProxy, Delegation Service, Community Authorization > Service. GSI does not include binding of attribute certificates > within PKCs > or PCs. So GSI is an overlapping but different set of features > than we are > talking about right here. > > Besides, to my knowledge, GSI supports vanilla PKCs as well as PCs. > > -Duane > > On Thu, Mar 19, 2009 at 1:27 PM, <m.riedel(a)fz-juelich.de> wrote: > > > 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 > > ----------------------------------------------------------------- > -- > > ----------------------------------------------------------------- > -- > > > > > > _______________________________________________ > > 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 ------------------------------------------------------------------- -------------------------------------------------------------------

1 0

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

20 Mar '09

Hi Aleksandr, >- 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. I refer to contacted as "accessed from a Grid client" w/o avoiding to create the EPR manually - instead the EPR has an URI in wsa:To and maybe referenceproperties to point to a particular resource instance behind the service interface. Q: Isn't A-REX not also accessible via EPRs? Thanks for clarification, 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:40 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman) > 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. > _______________________________________________ > 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