It can be as informal or as formal as you'd like, but it would help us with planning if the need was in the road map (I'll refrain from repeating the "No guarantees" speech :-)).
-Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Wed, Jun 25, 2008 at 1:34 PM, Larry Symms <[EMAIL PROTECTED]> wrote: > 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 >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
