W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Introducing a Session header...

From: Albert Lunde <atlunde@panix.com>
Date: Fri, 20 Jul 2012 13:01:39 -0500
Message-ID: <50099D03.80606@panix.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
CC: James Snell <jasnell@gmail.com>, Philippe Mougin <pmougin@acm.org>
I think the question of routing to load-balanced servers is at the other 
end of the problem space from federated logins, but I feel I should call 
people's attention to the Shibboleth projects statements on why single 
logout was a bad idea in their context:

https://wiki.brown.edu/confluence/display/CISDOC/Shibboleth+and+Application+Logout+Best+Practices

https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues

Shibboleth could function as a WebSSO protocol on it's own and was 
sometimes deployed that way, but with was designed to function in 
concert with a local WebSSO protocol, typically scoped per 
institution/identity provider.

Shibboleth and the commercial and free WebSSO systems I've encountered 
(CAS (layered on Kerberos), Sun Access Manager (which became OpenSSO)), 
all seem to use a nasty mess of cookies and dynamic html/JavaScript 
tricks, to achieve WebSSO.

SAML is pretty much designed to work within the limits of existing web 
browsers, though there was talk from time to about part of the Liberty 
Alliance being applicable to web services.

It's worth asking if there is a way to add features to HTTP that would 
make WebSSO easier to active without giving away too much in security.

Scope is a key problem. The "same origin" policy for things like 
cookies, applets, flash, has been recreated with different mechanisms 
for breaking it.
Received on Friday, 20 July 2012 18:02:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 18:02:18 GMT