Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] Sessions

Expand Messages
  • Rich Salz
    Wow, Jorgen, where to begin? I disagree with just about everything in your note. So, if only to get an alternate opinion into the record let me make state
    Message 1 of 13 , Apr 1, 2002
    • 0 Attachment
      Wow, Jorgen, where to begin? I disagree with just about everything in
      your note. So, if only to get an alternate opinion "into the record"
      let me make state the following. First off, this mailing list has
      already done more for interop than the SAML group ever will. :) I say
      that as a former member of the SAML lists.

      For quite some time, security sessions will be SSL/TLS, much more than
      it will be SAML. The current installed base of name/password over SSL is
      not going to throw that out for SAML as part of their move to XML. When
      you throw in the Liberty/Hailstorm issues, it's gonna be even worse.

      I predict SSL will dominate for at least the next two years.
      Therefore,application-specific sessions -- XML cookies, if you will --
      are more important for the foreseeable future. It would be nice if the
      frameworks supported a common mechanism to UDDI (gak) could have the
      same state mechanism as a Goole search, all supported by the SOAP
      infrastructure without having to recreate it all the time.

      A strong +1 to the suggestions.
      /r$
    • Jorgen Thelin
      ... Wow, Rich, I think you have misunderstand almost everything in my note ;-) ... That is because this group is focused on interoperability testing, and the
      Message 2 of 13 , Apr 2, 2002
      • 0 Attachment
        > -----Original Message-----
        > From: Rich Salz [mailto:r.salz@...]
        > Sent: 01 April 2002 15:18
        > To: soapbuilders@yahoogroups.com
        > Subject: Re: [soapbuilders] Sessions
        >
        >
        > Wow, Jorgen, where to begin? I disagree with just about everything in
        > your note.

        Wow, Rich, I think you have misunderstand almost everything in my note
        ;-)


        > First off, this mailing list has
        > already done more for interop than the SAML group ever will.

        That is because this group is focused on interoperability testing, and
        the SAML group is focused on standards setting.
        That was EXACTLY my point!


        >
        > For quite some time, security sessions will be SSL/TLS, much
        > more than
        > it will be SAML. The current installed base of name/password
        > over SSL is
        > not going to throw that out for SAML as part of their move to
        > XML. When
        > you throw in the Liberty/Hailstorm issues, it's gonna be even worse.

        I completely agree that transport level session features will remain
        important for a very long time. However, transport-level features such
        as SSL work on a hop-by-hop basis, so the only way to achieve end-to-end
        session functionality with a complex network infrastructure topology
        involving SOAP routers, SOAP firewalls and SOAP processing nodes is at
        the XML level. This can either be done on an application-specific basis
        or using some sort of "standardized representation".
        We cannot and should not stop people using app-specific ways of doing
        this if they want to, but I am saying that there are already emerging
        standard for this "standardized representation" without trying to invent
        yet another one. We already have more than enough competing and
        overlapping standards in the XML space to confuse the market for some
        considerable time to come!


        >
        > I predict SSL will dominate for at least the next two years.
        > Therefore,application-specific sessions -- XML cookies, if
        > you will --
        > are more important for the foreseeable future.

        See comments above, although I think am making a distinction between XML
        cookies being used at the application level and the same ideas begin
        used at the system level under the guise of infrastructure standards
        such as SAML Session Assertions, whereas you may not be.
        Nothing would stop you taking the SAML Sessions document and using it on
        an application-by-application basis right now. Or for that matter the
        OTA Sessions or UDDI Sessions systems. They are all just schemas, after
        all.


        > It would be nice if the
        > frameworks supported a common mechanism to UDDI (gak) could have the
        > same state mechanism as a Goole search, all supported by the SOAP
        > infrastructure without having to recreate it all the time.

        I agree it might be "nice", but this is not something that we
        (SoapBuilders) can mandate use of in practice for every application in
        the world!
        I suggest that over time the focus will move away from session support
        on an application-specific basis towards this being part of standard web
        services platform services once the necessary standards specifications
        (such as SAML Session Assertions) are in place and agreed.
        Transport-level session support such as SSL or HTTP Cookies will run
        alongside and throughout this evolution, and are totally orthogonal to
        it in my opinion.


        I don't think you actually disagree with me so much at all, Rich! :-)

        - Jorgen

        ----
        Try Cape Clear for all your Web Services software needs.
        http://www.capeclear.com/
        CapeConnect - Enterprise-grade Web Services Runtime Platform
        CapeStudio - Professional Web Services Development Suite
        ----
      • Rich Salz
        Okay, we agree more than I thought. :) I think cookie/set-cookie are a useful need to fill right now. You think SAML headers could/should be used right now, I
        Message 3 of 13 , Apr 7, 2002
        • 0 Attachment
          Okay, we agree more than I thought. :)

          I think cookie/set-cookie are a useful need to fill right now. You think
          SAML headers could/should be used right now, I think.
          /r$
        Your message has been successfully submitted and would be delivered to recipients shortly.