In our use cases we have a group of applications that share a timeout session managed by acegi filters. In the case of vendor apps that use CAS directly, then yes they would stay authenticated which is fine because in general those apps don't need the security that our in-house apps do. In the case of our more secure apps the use case is that when a session is inactive (max idle time) for longer than a specific length of time (each app can specify it's own inactivity timeout), the user will have to re-authenticate to refresh their max idle time to ensure that they have not left a session open in a public area. For kerberos tickets, it is assumed that the user won't leave their computer in a public place unlocked. At no point are we ending the CAS session so applications can choose to ignore our session timeouts.
For this to work would require some link between our timeout session and the CAS session. We are currently taking advantage of the fact that the CAS meta data is cached and returned on every Service Ticket validation within the session. In a custom metadatapopulator we create our timeout session and add the new session id to the metadata. ACEGI can then manage the session timeout with the session id returned in the meta data when validating the Service Ticket. This is not ideal but it works. Larry Symms Scott Battaglia wrote: > Troy, > > We tend to discourage applications determining the length of time that > a session is valid for (what if you logged out of all three apps and > then went to a fourth app 5 seconds later, why should that cause you > to sign back in?). Thus, you won't really find any tips, or built-in > mechanisms for handling this scenario. In general, we only support > the method where the CAS server can notify the clients that ITS > session ended. Applications calling back also requires that they are > aware of the TicketGrantingTicket (the SSO identifier) which is a bad > idea. > > -Scott > > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > On Mon, Jun 16, 2008 at 9:02 AM, Troy Bull <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Greetings > > First, I want to thank everyone in the CAS community as you all have > been very helpful in getting me up to speed. I must admit I was > nervous about this a couple weeks ago, now things are really working > quite well. That being said, my question. I have one last required > feature to implement. I have a cas server 3.2.1 and "a bunch" of > apps that do single sign on, single sign off. What I want to do is > implement a global timeout, say a user logs in to App A, then switches > to App B and Finally App C, when the last of these (A, B and C) times > out it needs to kill the CAS session so that CAS will no longer > re-authenticate the person. If anyone could point me in the right > direction, a wiki, a working example, any tips at all are greatly > appreciated. > > Thanks > Troy > _______________________________________________ > Yale CAS mailing list > [email protected] <mailto:[email protected]> > http://tp.its.yale.edu/mailman/listinfo/cas > > > ------------------------------------------------------------------------ > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
