Thanks for the very detailed and informative post, as always.
Just a quibble: SSO stands in fact for Single Sign ON. What you are asking for is Single Sign OFF.
The two are slightly different mechanisms, and using SSOn does not necessarily involve using SSOff. In fact I think you will find the majority of sso deployments does not.
There are a couple of reasons to this:
1 - performance
2 - business logic
In greater detail:
- in SSOn mode, whenever a user hits a participating server with no session cookie, or with an "anon_user" cookie, the server sends the user's browser to the SSO server via an http redirect, and the SSO server sends the browser back to the original page. This means basically 3 hits instead of one - not good for perfs unless you are on an intranet (plus your sso server should be able to scale when you add more participating servers)
- in SSOff mode, the same 'redirects game' is also done for every page view from an authenticated user, to check that his sso ticket is still valid. Which means even more general slowdown. Especially for intranet sites, where sso is usually deployed and most of the browsing is done in authenticated mode.
The business-logic mostly comes into play with session timeouts that might be different on different servers participating in the SSO ring: what happens when a user session times out on server A? Shall it end the SSO session globally or not? Also at many sites the extra-security implied by SSOff is not held in great value, whereas the commodity of SSOn is...
SSOn != SSOff
Gaetano
(30/01/2010 12:14 pm)
Just a quibble: SSO stands in fact for Single Sign ON. What you are asking for is Single Sign OFF.
The two are slightly different mechanisms, and using SSOn does not necessarily involve using SSOff. In fact I think you will find the majority of sso deployments does not.
There are a couple of reasons to this:
1 - performance
2 - business logic
In greater detail:
- in SSOn mode, whenever a user hits a participating server with no session cookie, or with an "anon_user" cookie, the server sends the user's browser to the SSO server via an http redirect, and the SSO server sends the browser back to the original page. This means basically 3 hits instead of one - not good for perfs unless you are on an intranet (plus your sso server should be able to scale when you add more participating servers)
- in SSOff mode, the same 'redirects game' is also done for every page view from an authenticated user, to check that his sso ticket is still valid. Which means even more general slowdown. Especially for intranet sites, where sso is usually deployed and most of the browsing is done in authenticated mode.
The business-logic mostly comes into play with session timeouts that might be different on different servers participating in the SSO ring: what happens when a user session times out on server A? Shall it end the SSO session globally or not? Also at many sites the extra-security implied by SSOff is not held in great value, whereas the commodity of SSOn is...