On Tue, Dec 4, 2012 at 3:07 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Will, > > On 12/4/12 2:47 PM, Will Nordmeyer wrote: >> Thanks for the quick response and the thoughts. a 5 minute >> timeout wouldn't be acceptable in our environment - theory being, >> if user A pulls his smart card out (but didn't log out of the app), >> and user B goes up to the machine within 5 minutes, he may have >> access to someone else's account in the application. So I was >> really hoping there was some way to trigger the session to expire. > > The only thing I can think of would be to have the web browser > complicit in the deal: if the browser can be configured to expire the > SSL session when the card is removed, then that is really the only > solution that will be truly secure. > That's a potential, but there are quite a few clients so I'm not sure we can impact the clients... interesting scenario we've got.
>> I'll keep looking, or suggest to my dev team that they write a >> little app that queries the card regularly and as soon as the card >> can't be found, logs out. > > Is it a valid use case to have the computer itself logged-in when the > card is removed? For instance, if you configured the machine to > auto-lock when the card was removed, then you might be able to do > other things, too (like kill the browser, which should kill the SSL > session). > Oddly enough, yes, it is a valid use case. we have specific scenarios where there are common use PCs that have a generic ID logged in, but they use their CAC and the browser to access the web application. > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlC+WBUACgkQ9CaO5/Lv0PBmeACeN5Y/m0G73Mplzufsys70uZPZ > EsoAn0Lh/cuM4vtC6Y5B8QekaDXff7eE > =mSK7 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
