-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Will,
On 12/5/12 7:33 AM, Will Nordmeyer wrote: > On Tue, Dec 4, 2012 at 3:07 PM, Christopher Schultz > <ch...@christopherschultz.net> wrote: 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. Okay, good to know. Well, the OS can certainly detect when the CAC has been removed. I think it's time to talk to some of the desktop IT folks to see what your options are. This is something that is going to have to be solved on the client side, not the server side. Now, if the CAC is definitely required in order to establish an SSL connection (can you confirm that? It's kind of important for my whole line of thinking, here), you could simply set the SSL session timeout to something typically considered foolishly low (like 1 second). That will significantly impact performance (every request will require a new SSL key negotiation), but should ultimately fulfill your requirement: the only way for a CAC to be removed yet still allow a post-withdraw request would be if the new and old users were face-to-face (discounting the usual edge-cases that crop-up on this list occasionally, like unlikely quantum phenomena, interference from Time Lords, etc.). It cannot, of course, prevent any physical attack (or mistake) on the client side such as one user taking another's CAC or a user forgetting to remove the card from the slot before leaving a terminal. You can fix those vectors with robust cables attaching the CAC to the user's pelvic bone, which I hear will be implemented starting in 2013. - -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/c48ACgkQ9CaO5/Lv0PB+1QCfRh43nJbEPtxcE//0y5rXluNe pQIAnRoOlpByn9bEAU31gp99pXt6WnWc =RZ6x -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
