On Tue, Dec 4, 2012 at 12:48 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Will, > > On 12/4/12 12:46 PM, Christopher Schultz wrote: >> On 12/4/12 12:08 PM, Will Nordmeyer wrote: >>> First off, thanks to all for the assistance getting my other >>> tomcat CRL issues working. Converted to APR and tcnative and >>> things seem to be loading, running well now. >> >>> Now, the question has come up - what happens when a user >>> authenticates with their Smart Card, but then pulls their card >>> and walks away. Is there a way for Tomcat to detect such an >>> event on the client and terminate/timeout the session? >> >>> In the googling I've done, I've seen suggestions about writing a >>> little java app that runs within our application and >>> periodically pulls something from the SmartCard - when the app >>> fails to get that piece of info, it terminates the app. >> >>> Is that the way to go? (and if so, is there sample code - I >>> know this isn't a java forum, but if someone's invented this >>> wheel before, that would be great). >> >> I'm certainly no SSL expert (especially with SmartCards involved), >> but if the SmartCard is required in order to set up an SSL session, >> you could set the SSL session timeout to some small-ish value (say, >> 10 minutes -- the default is 24 hours) and then require a new SSL >> session to be established every 10 minutes. That would require the >> SmartCard to be present for that renegotiation (this is my >> assumption). >> >> That way, you don't have to write any new software and maintain it >> on the client. >> >> Check out the "sessionTimeout" attribute on the HTTP/SSL >> connector. >> >> Hmm... I just re-checked and that option is currently only >> available for the pure-Java connectors -- and you just switched to >> APR to get your huge CRLs working. :( >> >> OpenSSL does have an SSL_CTX_set_timeout method, but it doesn't >> have any support through tcnative. If this is something that would >> help you, please let me know and I'll take a stab at implementing >> a tcnative method for this and then expose it through the >> <Connector> configuration. > > Answering my own question somewhat: the default SSL session timeout > for OpenSSL is actually 300 seconds (5 minutes) so that might work for > you. > > Of course, I might be wrong about the session timeout requiring the > SmartCard to be present for renegotiation. > > Let me know what you find out. > > - -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+N3QACgkQ9CaO5/Lv0PCOEQCgjv/OEhRGix5DMYJNsJam389C > NW4Ani2k+j+D3AfJ+q8i+UqssCCPAKLT > =Xz5U > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > Chris,
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. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
