been thinking through potential Apereo conference session proposals. It's this kind of browser behavior I had in mind when drafting this, which I rather like:
Title: The Thrill of The Hunt - Tracking and Terminating Single Sign-On Sessions in CAS and Shibboleth Abstract: An exploration of concepts in, existing functionality for, and good practices in tracking and terminating single sign-on sessions, in CAS (the Central Authentication Service) and Shibboleth. By "tracking", think Google Analytics and within-SSO-application functionality. By "terminating", think logout, single logout, browser closing, operating system session ending, hard drive reformatting, and high atmosphere electromagnetic pulses. The latter isn't a best practice, but the demonstration of out-of-the-box browser behaviors around secure session management may drive you to consider it. This sound like a presentation worth having at Apereo 2013? Andrew On Thu, Feb 28, 2013 at 4:28 PM, Ohsie, David <david.oh...@emc.com> wrote: > I agree with Andrew that if the browser is doing that, then there is > probably nothing on the server side that you can do to fix it. And > recently I've been more chrome focused, so I probably missed the firefox > change. I'm going to do some testing now... > > Thanks to both Andrews for the explanation. > > david > > -----Original Message----- > From: Andrew Morgan [mailto:mor...@orst.edu] > Sent: Thursday, February 28, 2013 3:30 PM > To: cas-user@lists.jasig.org > Subject: RE: [cas-user] Public computer login and CAS > > Sometime around Firefox 15 or 16, the behavior changed. If you close > Firefox by clicking the [X] button on the window, when you re-open Firefox > all of your session cookies are still present. If you close Firefox by > choosing File > Quit, when you re-open Firefox the cookies are gone. > However, if you choose History > Restore Previous Session, then all the > cookies and pages are restored. > > If you know of a server-side way to prevent this, I'd love to hear it! > > Andy > > On Thu, 28 Feb 2013, Ohsie, David wrote: > > > Andrew, my experience using firefox and chrome (and I think IE as well) > to > > access CAS protected applications differs. If the cookies are set right > by > > the server, it is sufficient to kill the browser to force a new login. > > > > > > > > I'm not claiming that public internet terminals are safe or that there > > are no ways to exploit this, but I would say that if your application > > remains accessible after your browser is restarted, then you should be > > looking at your application setup and then your CAS setup to ensure > > that the cookies are set to expire upon the end of the session (and > > that the caching control is also set properly for sensitive pages). > > None of this is foolproof, but basic safeguards should be maintained. > > > > > > > > David Ohsie > > > > Software Architect > > > > EMC Corporation > > > > > > > > > > > > From: Andrew Petro [mailto:ape...@unicon.net] > > Sent: Thursday, February 28, 2013 2:43 PM > > To: cas-user@lists.jasig.org > > Subject: Re: [cas-user] Public computer login and CAS > > > > > > > > I believe this is a well-known issue. > > > > > > > > Modern browsers take liberties with their interpretation of the > > duration of session-scoped cookies, such that merely closing the web > > browser is no longer sufficient. > > > > > > > > Users need to either explicitly log out of CAS to end their single > > sign-on session and out of your application to end their session with > > your application, or explicitly log out of their operating system > > desktop session to prevent others from accessing it. The latter is far > preferable. > > > > > > > > You can try to make explicit logout from CAS have a side effect of > > single logout callbacks to your application to also log the user out > > of the application, but this doesn't address the root issue of there > > being a window of time within which the end user has valid session > > cookies that the browser did not clean up on browser close such that > > re-opening the browser can resurrect them. > > > > > > > > Known shared browser installs can and should be configured to > > implement a tighter understanding of what a session cookie's duration > > ought to be. To the extent that you're curating browser installs for, > > say, known-shared computers in computer labs on a campus, those > > browser installs should be so configured. Internet cafe purveyors ought > to do this. Most probably don't. > > Then again, I just assume that all Internet cafe computers are > > equipped with at least one malware keystroke logger. [1] > > > > > > > > Otherwise, end users really really should be afforded the opportunity > > to fully log out of their operating system sessions, and should do so > > when leaving a shared computer. > > > > > > > > > > > > > > > > [1]: A quick Google search suggests I'm not far off -- four out of ten > > internet cafes providing keystroke loggers with their lattes in this > > one study. http://www.jiti.net/v11/jiti.v11n3.169-182.pdf > > > > > > > > > > > > > > > > On Thu, Feb 28, 2013 at 2:08 PM, Ohsie, David <david.oh...@emc.com> > wrote: > > > > Do you have "Remember Me" turned on? > > > > > > > > If not, it is possible that either the session cookies from your site > > are persistent (with an an explicit Expires/MaxAge) or else the cache > > control headers are allowing some pages to remain withing the browser > cache. > > > > > > > > From: Danny Sinang [mailto:d.sin...@gmail.com] > > Sent: Thursday, February 28, 2013 12:55 PM > > To: cas-user@lists.jasig.org > > Subject: [cas-user] Public computer login and CAS > > > > > > > > Hi, > > > > > > > > I noticed that closing and reopening my browser allows me to access > > protected webpages on my CASified site. > > > > > > > > This could be a problem if I logged in from a public computer > > (internet cafe, etc). > > > > > > > > Is there a way to secure against this ? > > > > > > > > Regards, > > Danny > > > > -- > > You are currently subscribed to cas-user@lists.jasig.org as: > > david.oh...@emc.com > > > > > > > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > > > > > -- > > You are currently subscribed to cas-user@lists.jasig.org as: > > david.oh...@emc.com > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > david.oh...@emc.com To unsubscribe, change settings or access archives, > see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
