Troy, > I have inherited our CAS server implementation.
Congratulations. There's a lot of joy to be had in working with CAS. Can I ask which CAS server implementation you're working on? These sound like potentially interesting requirements and customizations you have, and I always like to encourage folks to be listed on the listings of CAS adopters, both in the wiki where you can add arbitrary writeups of what you're needing and doing, and on the CAS website. http://www.ja-sig.org/wiki/display/CAS/CAS+Deployers http://www.ja-sig.org/products/cas/community/deployers/index.html Let me try to articulate your requirements back to you, and then suggest how they might be implemented. Requirements: 1) User sessions with Secure Applications should expire after a short period of inactivity, and users should have to re-authenticate again establish an authenticated session with these Secure Applications. In this way casual Session Hijacking via unattended browser sessions will be discouraged by controlling the window of time in which unattended browser sessions are live. 2) When a user explicitly logs out of the CAS server, his or her authenticated sessions with Secure Applications to which the user authenticated via CAS should be destroyed. In this way casual Session Hijacking via unattended browser sessions will be discouraged by allowing users to de-fang these browser sessions. (This doesn't in the general case work, of course, since the user may well have accessed other applications, e.g. GMail, leaving open interesting sessions, even non-obvious such sessions latent in cookies but not presented in currently open browser windows. In general it remains advisable that users fully close their web browsers when done using web applications.) Suggested technical realization of this requirement: 1) After a user authenticates to a Secure Application, after N minutes of inactivity, the session for that particular Secure Application should be destroyed, such that if the user wishes to further use the Secure Application, he or she must again present username and password to CAS. The session expiry can be realized with setting a session timeout of N minutes in the Secure Application and aggressively separating the secure and casual portions of the application such that they do not share a session (so that the non-secure activity doesn't keepalive the session to the secure portion). This might be realized using two web applications, one for each security scope, enjoying single sign on between for user convenience in making the transition from secure to insecure but stateful application. The "must again present username and password to CAS" bit can be accomplished by using renew=true in the secure application. 2) Implement the CAS 3.1 / CAS 3.2 single sign out callbacks. It's quite possible I haven't fully understood your requirements and you need to do something else. Or maybe you can make the above your requirements. :) [ My question is two fold, firstly any general advice you can give me would be greatly appreciated, secondly, should i scrap all this and start over with a plain vanilla (current release) CAS server? ] I hope the general advice above helps. And, yes, gut reaction, I do think you should scrap what you've got and go with a plain vanilla latest CAS server release. Welcome to CAS. Andrew Troy Bull wrote: > Greetings > > I have inherited our CAS server implementation. I am pretty familiar > with web security and how it works but brand new to CAS. We have > several web apps that participate in SSO. They are spring apps and > use Acegi on the client side. > > I think the version of CAS I currently have installed in prod is > 3.0.6. There have been various changes / extensions; to this, I am > not sure how many or the size of the changes. I have been asked to > implement a "global timeout" (explanation to follow). The contractor > that was working on this project prior to my coming on board made > changes to 3.0.6 to do this global timeout but has never tested his > changes (he is now gone). > > Global timeout issue: > > Current Situation: When a user leaves the secured site and remains on a non- > secure page in the same browser window past the 15-minute inactivity > limit, then > the redirection of the secured site to complete session logout does not > happen. > > Proposed Solution: A login registry will be added within the authentication > mechanism so as to monitor user's activity with the secured > applications, and log them out when they are no longer active with any > sessions. > They will remain active if they have even one active session with any of the > secured applications. > > This is implemented currently (but untested and probably not complete) > by setting up a registry in the CAS server that keeps track of every > application you are logged into, then with a session invalidate > listener (or filter or something) fires on sessiobn expiration that > will remove that particular app from the registry in CAS. When there > are no more entries in this registry you are logged out and our CAS > will no longer auth you. Sorry to be so dense about this but I am > still in the process of trying to understand this all and CAS as well. > > > This line "the redirection of the secured site to complete session > logout does not happen", refers to a jsp callback in each of our apps > that blow away the session for that app. So I click logout, and a jsp > page comes up that calls a bunch of other jsps (one for each > participating app). Those pages blow away the session in each app. I > think this is where the problem comes from, if I navigate away from > the site there wont be any callbacks to log me out of each app. > > > My question is two fold, firstly any general advice you can give me > would be greatly appreciated, secondly, should i scrap all this and > start over with a plain vanilla (current release) CAS server? > > > Thanks > Troy > _______________________________________________ > 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
