- From: Albert Lunde <atlunde@panix.com>
- Date: Fri, 20 Jul 2012 13:01:39 -0500
- 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 UTC