tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Nordmeyer <quark...@gmail.com>
Subject Re: Recognizing certificate removal (SmartCard)
Date Tue, 04 Dec 2012 19:47:29 GMT
On Tue, Dec 4, 2012 at 12:48 PM, Christopher Schultz
<chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message