Re: Introducing a Session header...

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