Re: [soapbuilders] Sessions
- 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.
> -----Original Message-----Wow, Rich, I think you have misunderstand almost everything in my note
> From: Rich Salz [mailto:r.salz@...]
> Sent: 01 April 2002 15:18
> To: email@example.com
> Subject: Re: [soapbuilders] Sessions
> Wow, Jorgen, where to begin? I disagree with just about everything in
> your note.
> First off, this mailing list hasThat is because this group is focused on interoperability testing, and
> already done more for interop than the SAML group ever will.
the SAML group is focused on standards setting.
That was EXACTLY my point!
>I completely agree that transport level session features will remain
> 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.
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!
>See comments above, although I think am making a distinction between XML
> 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.
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
> It would be nice if theI agree it might be "nice", but this is not something that we
> 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.
(SoapBuilders) can mandate use of in practice for every application in
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! :-)
Try Cape Clear for all your Web Services software needs.
CapeConnect - Enterprise-grade Web Services Runtime Platform
CapeStudio - Professional Web Services Development Suite
- 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.