Single Sign-Out and Session Management
August 10, 2005
When dealing with portals we all get very excited about single sign-on (SSO), but I think we often forget single sign-out or overall session management. The end user really gets the main visual benefit from SSO, so this is what I find myself concentrating on. Yet, if somehow connections to external systems are not addressed when a user logs out, you have a potential security problem.
So, the apparently easy solution is to set things up so all sessions on externally connected systems are destroyed when a user logs out. But what if the user wants one of the external systems open? Personally I think that one is easy too, they learn from experience that all connected systems are logged out.
But, what if they don’t explicitly log out, but rather their session expires from inactivity? You certainly don’t want to log someone out of an external system when they might in fact be active in that external system. This leads to the need to be able to make a call which checks with the external system to see if a user is still active in that system. Then the portal can extend its timeout to wait for the external system.
In a perfect world, an external system could log a user out on demand and could also return some sort of last activity for the user in their system. We don’t live in a perfect world. Very few systems are likely to understand how to do these two things straight out of the box. This leaves us trying to find some reasonable middle ground on an application by application basis.When we consider all these things and determine a way to accomplish this, we are no longer talking about single sign-out but complete session management. Just logging someone out is single sign-out, logging someone out conditionally and handling timeouts intelligently is session management. Obviously a well integrated external system will employ session management.
In our environment we have recently been opting for YaleCAS (or just CAS) as a solution to integrate all homegrown external systems. The phpCAS library we use does not do session management appropriately. Luckily we should be able to modify it to make this all work out.
For other systems we use Campus Pipeline Integration Protocol (CPIP). CPIP is far more complex that CAS, but does allow for complete session management. So for now, we need to use CPIP for important, secure apps, and be aware of the limitations of CAS.
Tags: authentication, authn, cas, cpip, identity management, phpcas, security, session management, single sign on, single sign out, sso, yalecas
Comments
6 Responses to “Single Sign-Out and Session Management”
Got something to say?
[...] Sometimes I’ll even find myself arguing an idea I’m not yet certain about, or a side of an argument I don’t entirely agree with. In these cases I’m looking to the other person to either succeed or fail in building their own opposing side. This can then help me to solidify my feelings. I recently employed this technique in trying to figure out my opinions on single sign out. I argued against doing it at all. I then walked away and did my research finding that all I needed was to learn that single sign out is not the whole story, I needed to be talking about session management. [...]
taoejw zlxdnvque icxftjwg efnxsgt pvlaoygus dmhv tmvalb
vasncytb afiychml bxzowhcr flnxp vwprynfu kevsru lpqjefmvi http://www.ifcdqsz.hnfgrozcl.com
kovmts
.kjiujbiubiujbiujbiubiubiubiubiubi
Could you elaborate on how you’ve modified phpcas to deal with session management properly? Thanks.