Scott, I don't see anything in there that would get us the hooks that we need. Would you like me to write up a formal use case?
Larry Scott Battaglia wrote: > 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] > <mailto:[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]> > > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Yale CAS mailing list > > [email protected] <mailto:[email protected]> > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > _______________________________________________ > 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
