Larry, all, If going forward application callback or any of its derivatives is something that would be valuable, please be sure that its use case is covered on our roadmap:
http://www.ja-sig.org/wiki/display/CAS/CAS+Vision+and+Roadmap Obviously, being on the roadmap doesn't guarantee inclusion (especially if it compromises security) but it makes it more likely that at least the hooks would be there. -Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Mon, Jun 23, 2008 at 11:34 AM, Larry Symms <[EMAIL PROTECTED]> wrote: > 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 >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
