Authentication Definition
September 26, 2005 | 5 Comments
According to Internet2, authentication or AuthN is defined as:
Authentication is the process of establishing whether or not a real-world subject is who or what its identifier says it is. Identity can be proven by:
- Something you know, like a password
- Something you have, as with smartcards, challenge-response mechanisms, or public-key certificates
- Something you are, as with positive photo identification, fingerprints, and biometrics
Once again, this is a nice concise definition. It’s good to have these clearly defined to eliminate any confusion or debate when discussing, similar to what I did with my “Single Sign-On Definition” post.
Tags: authenticate, authentication, authn, biometrics, challenge-response, definition, fingerprints, identity management, internet2, middleware, password, passwords, smartcards
Single Sign-Out and Session Management
August 10, 2005 | 6 Comments
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