Christopher Schultz 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.

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).


Sorry for barging in where I know little myself.
In the thread "Tomcat 7 SSL Session ID", a recent post by EJP may have a bearing on this discussion, maybe.

Other than that, and without any pretense at offering a "solution" to the present issue, maybe this is the point where one needs to step back and ask oneself if this is really a problem of the application.

If the environment is such that it is a concern that one might login using a card, then remove the card and walk away, leaving the workstation logged-in and a session open with some security-conscious application, for someone else to use at will, then maybe this is not a problem of the application at the other end, but a problem with the environment ?
What for example if that same person walks away while leaving their card in the 
reader ?



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to