- pgi-wg - lists.ogf.org

More information on Security Plumbings (with GLUE dependencies)
by Morris Riedel 27 Mar '09

27 Mar '09

Hi team, So in my mail from yesterday evening, I referred again to the plumbings and before I will draft now slides/factsheets I would like to shortly point out again what I mean with it - maybe more explicitly - although this has been already discussed with several AuthZ specialists in prior OGFs or other events (e.g. Valerio Venturi, etc.). Major idea: Simple + Stupid - not cracking the security dilemma, but creating a significant step towards DEFINING the common security models/plumbings: # First of all, the clients choose the client technology they like or find convenient for their science (maybe even business) - I think that's something where we all agree to. ###### 1 - Pluming Type: Authentication (either-or) = TWO choices here: PGI_AUTHN_ENDENTITY or PGI_AUTHN_PROXIES (meaning one has to support the chain checkings) # an end-user uses this client with an PGI out-of-band mechanism (maybe LDAP queries) to retrieve GLUE-based information about a certain endpoint getting: # endpoint contact information (i.e. BES URL) AND # GLUE SECURITY.AUTHENTICATION capability of this endpoint # The value of this capability is either PGI_AUTHN_ENDENTITY or PGI_AUTHN_PROXIES # The client know how to contact the endpoint on the TLS level then, which is in PGI the foundation for AUTHN ###### 2 - Plumbing Type: Attibute-based AuthZ (at least one of it) = TWO choices here: PGI_AUTHZ_AC or PGI_AUTHZ_SAML # an end-user uses his client again (or retrieved information with the first request) with an PGI out-of-band mechanism (maybe LDAP queries) to retrieve GLUE-based information about a certain endpoint getting: apart from the above information: # GLUE SECURITY.AUTHORIZATION capability of this endpoint # The value of this capability is AT LEAST ONE of PGI_AUTHZ_AC, PGI_AUTHZ_SAML - maybe even both # The client knows how the attributes have to be transported to the endpoint then so that the endpoint understands them and uses them for attr-authz based on resource-owner policies. #### The bottom line is that we just have to define a few bits and pieces precisely that are PGI_AUTHN_ENDENTITY, PGI_AUTHN_PROXIES , PGI_AUTHZ_AC, PGI_AUTHZ_SAML. Each of it well-defined with respect to used standards, IETF RFCs, OASIS SAML, like Etienne listed... With that we significantly narrow down the possibilities in terms of security while we have two different types of plumbings that are easy to understand: AuthN + Attr-AuthZ. Maybe we need another plumbing because of the difference of using the incompatible general proxies and GSI proxies on the TLS level, but both are part of the AuthN plumbing type. Maybe in future this incompatibility is fixed and then one plumbing might be just removed without changing standards. ### Looking from the end-user point of view seeing a united federation of Grid systems, the user uses his client that may only support one plumbing in terms of attr-AuthZ . In that matter the client only queries from the out-of-band-information service GLUE-described endpoints that only supports these systems that match with the supported plumbings from the client (and matched other requirements like cores/memory/interconnection of course). Of course, we have to agree on the transported attribute structure - but the deployment of plumbings is policy of the respective infrastructures. The infrastructures may even setup two endpoints with different plumbings to support more clients that is still better than having a complete middleware co-existence at the resource level... Hence, the idea of the plumbings was to have a relatively easy to understand mechanism to describe what end-user clients require to understand when performing interoperability use cases. Also, as you see in my figures, the security plumbings are close to the information plumbing (i.e. GLUE) meaning that both have to be installed in a working house. I hope the idea of plumbings got much clearer now, but I will try to provide some figures for the telcon this afternoon. Like the reference model term, also the plumbings term can be changed to something more understandable. Of course, the plumbings are only my suggestion coming from GIN interop. use case experience and working in the field of interop for many years now - of course its still subject to discussion - but it has much potential to bringing us closer together NOW instead of waiting for a huge common security framework in the future that may not even be defined (+deployed!) before the Grid fundings are stopped... Finally, with looking from a slightly distance on the group, I'm happy that we are still in the process of jointly discussing in the group and no one leaves and thus I'm confident that we can act as a team to provide something useful to the Grid community, which is maybe not the perfect solution in terms of security, but a good step forward bridging different worlds - achieving interoperability at least between several Grid islands... Your co-chair, 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)

1 0

FW: OGF PGI - Security Model
by Morris Riedel 26 Mar '09

26 Mar '09

Hi interop-friends, firstly sorry again for missing the last days. I have seen many comments since then and unfortunately see that the different threads had been united again mixing things up a bit (maybe it was nevertheless useful). Finally Steven made a good point with 2-3 sec. models out of n^n ones. So finally we have reached to the ideas of my suggestions of having well-defined different security 'plumbings' (aka 2-3 well-defined security models). I don't care about its precise name... I just used this term 'plumbings' because it had no pre-definition in security, please compare the vertical lines in the interoperability reference model - they are just more simpler defined in terms of AUTHN and ATTRIBUTE-AUTHZ than the long list presented by Etienne but very much of its content is the same. I presented this since OGF23&OGF24 within GIN with the two ways (left AC and right SAML) and the open issues to work on, but never had chance to write it down in written text yet: http://www.ogf.org/OGF24/materials/1409/2008-09-16_GIN_SessionTwo_OGF24_Ried el_v1.pdf Slide 6 and others... :-) Especially on this slide 6, even outsiders of our production Grids (like Chris Smith) understood the meaning of the slide and I got positive feedback on this from numerous sides. We all want to reach interoperability here in this group. We want to do this for certain interop applications. We shouldn't underestimate the power of the combination of the different security elements - nailing down the currently typical ways of using TLS with certs, Attr-Authz, Attributes, Constraints/Restrictions in conjunction are already powerful. We will have precise PGI definition of aligning such building blocks even if there are two ways in the end - but there are less than n^n ways that are currently out there in the security field combining different blocks, profiles, etc.... Also, what the middleware supports and what is then deployed in turn on particular production Grids are both different stories! For instance, UNICORE can be used with the proxy-style (plumbing) enabling interoperability with gLite, ARC, NAREGI. We have done this for many interop use cases, for instance with portals requiring proxies. However, there should be also another full X.509 (plumbing) available where other common approaches can be used and then expressed correctly via GLUE in interops as well used other infrastructures with different policies. I even foresee that there could be used more than one plumbing in parallel. We may have still single islands in a way - but we also come closer together, which is a good first step towards the right direction and my suggestion to move forward in this complex security discussion since its beginning. Which particular plumbings of both common approaches are then used in production Grids is policy of the respective deployments of the middlewares and may even depend on the underlying interop application use cases which should be our most significant drivers (!) - BUT the main point is that we know where we talking about in interop work without having n ^ n different security setups available! Only one short example: # There is one DB with attribute information about of end-users (used by VOMS) # Agreeing on the attribute semantics&Structure is important # VOMS support interface for retrieving AC and also SAML assertions # There are two ways of transporting the attributes that come out of the same DB (used for later attr-authZ) # Both transports have correct AuthN mechanisms (clarifies AuthN+ID-authZ) # In the end using different plumbings, but the same attributes are then evaluated against a policy describing maybe having equal policies based on the same transported attributes of the same DB (re-alignment!) # In the end what matter are the attributes a user has and what the policy decides to do with them (if its XACML, ACLs, etc. is unimportant here), but we should talk about the same things once we evaluate attributes. I try to provide you more figures, etc. hopefully tomorrow - but on my slides a lot of it has been already presented numerous times... we just have to nail it down - but in a more KISS style = Keep in Simple and Sweet/Stupid! Your co-chair, 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) >------Original Message----- >-From: pgi-wg-bounces(a)ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of >-Steven Newhouse >-Sent: Thursday, March 26, 2009 7:16 PM >-To: Moreno Marzolla; Duane Merrill >-Cc: pgi-wg(a)ogf.org; edges-na3(a)mail.edges-grid.eu; lodygens(a)lal.in2p3.fr >-Subject: Re: [Pgi-wg] OGF PGI - Security Model >- >-> Having to build >-> adapters to translate (if possible) credentials in different formats >-is >-> a compromise which is more reasonable than having to wait for all the >-> middlewares of the world to move towards a common security >-> infrastructure. >- >-In the short term... documenting and defining the 2 or 3 security models >-is real progress. If a service only supports one of these I do not see >-this as a problem - for all the reasons given. Providing credential >-translation services to provide 'shims' (or bridges between these >-islands) as an interim solution makes this work. Its a low risk to >-individual services - they maintain their current stability - and can >-migrate over time to support both or the most 'popular' one - let the >-market decide! >- >-Each service can then advertise the mechanisms it supports and clients >-can locate credential translation services as required. >-_______________________________________________ >-Pgi-wg mailing list >-Pgi-wg(a)ogf.org >-http://www.ogf.org/mailman/listinfo/pgi-wg

1 0

VO management in OSG
by Oxana Smirnova 24 Mar '09

24 Mar '09

Hi all, I just attended a talk at CHEP09 presenting something called SVOPME - an environment to manage VO privileges in Open Science Grid (which is a production Grid infrastructure, admittedly underrepresented in OGF). Can be of interest for us. See the slides here: http://indico.cern.ch/contributionDisplay.py?contribId=188&sessionId=62&con… Cheers, Oxana

1 0

Apologies for not contribute to discussions
by Morris Riedel 24 Mar '09

24 Mar '09

Howdy folks, I mentioned this to some people already - but just for the understanding of others - I'm involved in JSC in a triple AAA priority event related to our fundings for the next years - therefore I can't work on PGI until Thursday. Please contact Shahbaz Memon (m.memon(a)fz-juelich.de) in urgent cases about BES. Please contact Shiraz Memon (a.memon(a)fz-juelich.de) in urgent cases about GLUE. However, I'm keen to have another Security Phone Con on Friday based on Factsheets prepared on Thursday. 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)

1 0

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

23 Mar '09

hi, can you not just use the full end-entity certs with extensions (i.e. put ACs there=? 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 3:55 pm Subject: Re: [Pgi-wg] Sec: Agreement on attributetransportmechanismsforAttrAuthZ > m.riedel(a)fz-juelich.de wrote: > > Hi, > > > >> - This is the problem you mentioned which we experienced during > the > > OMII-EU project: BES clients were not executing the delegation > > operation, so the service did not have any delegated credentials > to use. > > We then implemented a horrible workaround in CREAM which was > fine for > > demonstration purposes, but unfortunately can not be applied for > any > > real use. > > > > > > ok, that's interesting - if you don't extract the proxy > obviously then from TLS level during AuthN steps - why is there > still a proxy support needed on the TLS level then?! > > I answer your question according to the understanding I just > gained from > our security experts, so bear with me :-) > The gLite middleware relies on VOMS extensions to associate roles > to > users according to the VO they belong to. If you use plain X509 > certificates, of course you don't have any VO information there, > so it > is not possible for services to assign roles to the bearer of > those > certificates. > Suppose you want to submit a job to CREAM, and the job needs to > stage > external data to/from a service which DOES require VO extensions > in > order to perform authorization decisions. In this situation you > need at > least to delegate to CREAM a certificate with VOMS extensions (the > delegated certificate will be used by CREAM to access external > resources > on behalf of the user). > Of course, if you have an X509 certificate signed by a > "conventional" > certification authority, you cannot stick VOMS extensions inside > it. For > this reasons, when gLite users want to interact with CREAM > directly, > they first create a VOMS proxy certificate via the voms-proxy-init > command. Thus, using a proxy to interact with CREAM is only needed > to > have VOMS extensions inside the credential used to interact with > the > service. > If your job does not require to access any external service, OR if > that > external service does not rely on VOMS extensions, then you are > perfectly fine using plain X509 certificates only. > > Moreno. > > -- > Moreno Marzolla > INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy > EMail: moreno.marzolla(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 ------------------------------------------------------------------- -------------------------------------------------------------------

3 4

Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
by Jens Jensen 21 Mar '09

21 Mar '09

Morris Riedel wrote: > 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. > Trying to pick up the thread, I have read it now (not necessarily understood :-)... I skimmed PGI_COMM v0.3, mainly asking to clarify whether things are in scope. Note the difference between PKC validation is that in Globusy grids the web service must have the whole CA certificate chain installed from the EE cert to a self signed root; for a proxy the client is required to supplement the chain by sending the intermediate certificates (viz, the user certificate and intermediate proxies). There are cases where this provides additional security. Thus a web service provider needs the CA hierarchy installed - this is (being) documented by CAOPS. In a sense the proxy hierarchy underneath it is more dynamic. In a sense this makes it more usable at the cost of some loss of security. One other point, nobody so far (that I could see) mentioned the gLite delegation service. This would provide a way to keep delegation but still have SSL/TLS sockets. One other point. Most HTTPS/SOAP connections in practice are opened on demand. Every time the client makes a call (I don't believe anyone ever implemented notifications, instantiated from the server), a new SSL socket is negotiated. This turns out to be comparatively expensive, and there are suggestions for how to improve this. Is this within the scope of the document? There are proposals for streaming SOAP, is that within the scope of this document? Support for this would be useful for some of our applications. One other point, turns out there is some debate about the role of the trust anchors in SAML-based trust federations (Shibboleth ones specifically). Their approach is in practice often distinct from typical grid PKIs. Is this within the scope of the document? Is the work supposed to be specific to SOAP or are other things carried by HTTPS or HTTPG relevant? One thing that would be useful is to have an overview of which WS-* are actually implemented in usable libraries. I will not touch WS-Anything unless it has a (preferably open source) implementation in C++ which interoperates with a Java ditto (usually Java supports WS-Anything first). Regards --jens

1 0

Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces
by Steven Newhouse 21 Mar '09

21 Mar '09

Hi Morris, I'm confused by the context here... are you suggesting we look to standardise the VOMS interface (or the service that serves up the proxy that) or the proxy and its content itself? Thanks, Steven Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse > -----Original Message----- > From: pgi-wg-bounces(a)ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf > Of Morris Riedel > Sent: 19 March 2009 14:22 > To: pgi-wg(a)ogf.org > Subject: [Pgi-wg] Sec: Agreement on supported Attribute Authority > Interfaces > > Hi PGI security folks, > > another issue I see is the supported attribute authorities and (more > notably) their interfaces. > > Taking our experience from GIN into account and addressing the message > of Steven (EGEE) there are still two interfaces to consider in terms of > VOMS. > Also, as an alternative AA there is Shibboleth quite much used in the > space. > > ### goal > > (a) > We are discussing which AA can be used in PGI to retrieve attributes... > > (b) > ...because we want to find out which interfaces have to be supported to > get attributes... > > > (c) > ... in order to know more precisely which types of attribute transport > mechanisms we have to support in PGI. > > ### Possible scenarios > > A. A user contacts a non-WS-based classic VOMS with a proprietary > interface, but gets a standardized RFC AC back with the attributes > signed by the VOMS. > (later on these are used within extensions of RFC proxies for attr- > authZ) > > B. A user contacts a WS-based VOMS with SAML-REQUEST-interface standard > and gets a standardized SAML Assertion back signed by the VOMS service. > (later on these are used within WS-SecExt within SOAP Headers) > > C. A user contacts a Shibboleth system (possibly w/o WAYF) using SLCs > with SAML assertions inside its extensions. > > D. A user contacts MyProxy with a stored proxy using ACs in its > extension (implies no new attribute transport mechanism), but possibly > a new interface of getting (indirectly) attributes. > > > I see the agreement on the elements of this e-mail thread as a > prerequisite to agree on the mechanisms of which attribute formats we > support and how we convey attributes precisely (separate email thread). > > ### Possible conclusion: > > A. We only reference in our profile possible ways of retrieving either > ACs or SAML assertions (e.g. by pointing to the SAML-request document > that is in public comment currently as mentioned earlier). We do not > intend to profile how exactly a user gets its attributes. > > B. If we agree on A - we indirectly agree on attribute push since in > the attribute pull mode - for interoperability reasons - the interface > of getting attributes must be known so that the middleware can contact > it on behalf of the user! > > C. We deal with RFC ACs > > D. We deal with SAML assertions > > E. We only consider C+D in the first iteration of the profile > > > > ### open Questions > > Q: Can we agree on these conclusions? Are there any comments - > something I missed? > > Q: Is there any production infrastructure that largely supports > Shibboleth w/o supporting VOMS either in classic or WS style? > > > > > Please consider the attribute - and its transport mechanisms out of > scope in this e-mail thread. > > > 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) >

2 2

GSI OpenSsh
by Duane Merrill 20 Mar '09

20 Mar '09

In theory, rfc-3820 proxy certs should not have any effect on TLS wire protocol. For various reasons, different versions of GSI-OpenSSH *have* changed the wire format in different ways. (Shame on them.) Out of curiosity, are there any published/publicly-availabe descriptions of these deltas? Duane

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

ok, consider two EPRs with exactly the same wsa:to elements and only the referenceparameter is different indicating the different resources behind the service interface. How do you visualize/deal with the different EPRs if they are opaque!? 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 3:39 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman) > On Fri, Mar 20, 2009 at 10:30 AM, <m.riedel(a)fz-juelich.de> wrote: > > > > > but if I have an EPR obtained from UNICORE-BES (wsa:To + > > referenceproperties) that a client of ARC can't handle it > rightly would > > break our desired interop by maybe just using wsa:To URIs... > > > > The beauty of WS-Addressing is that reference parameters are > opaque. As a > client, *you don't need to know* how to handle them. And as a > service, you > don't need to know how to handle any other service's reference > parameterseither. Only your own (and only then if you decide to > have them.) > > -Duane > ------------------------------------------------------------------- ------------------------------------------------------------------- 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 attributetransportmechanismsforAttrAuthZ
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

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 ------------------------------------------------------------------- -------------------------------------------------------------------

2 1