Intermittent Digest Authentication User Lockout

[Bruce Weertman <br...@iris.washington.edu>]

I am running into an intermittent problem with Digest-Authentication. This is with tomcat 7.0.39

The issue appears to be that clients will occasionally get locked out for 5 minutes. The problem
appears to happen with there is a combination of good password and then bad password, or the
other way round. We have also seen the problem happen when our load balancer is not sticky. 

My understanding is that digest-auth really should not work if the load-balancer is not sticky since there need to be information
sent from the server to the client in order to make the authentication. We have since made our load balancer sticky, hoping that 
this would resolve the issue. 

Actually, I should make a clarification here. It’s not “clients” that are getting locked out. It is “users”. 

Once a user gets into a bad state the account gets locked out until a 5 minute period goes by. 

Looking at the tomcat source code, I see DigestAuthenticator.java line 147: 
protected long nonceValidity = 5 * 60 * 1000;

Sorry if this sounds confused - I’m confused. I can say this. We’re seeing users get locked out for
5 minutes at a time. Having the load balancer not being sticky would definitely cause the problem,
but after making them sticky, we still see the problem with at least one client program. The client
programs are mostly non-webbrowser based.

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

Re: Intermittent Digest Authentication User Lockout

[Bruce Weertman <br...@iris.washington.edu>]

I’ll answer my own question.

Short story: Everything was working as designed.

The problem, as we now understand it, was in fact due to the LockOutRealm

http://tomcat.apache.org/tomcat-7.0-doc/config/realm.html#LockOut_Realm_-_org.apache.catalina.realm.LockOutRealm

The load balancer not being sticky was causing bad authentications to be sent to the
backend tomcats. Eventually, enough bad requests were being sent to the backends
that they would each lock out. Sometimes, by luck authentications would work due to
the Load Balancer sending requests back to the same backend as the originating response.
That all makes sense. Has nothing to do with the  nonceValidity timeout. 

Also, for some reason, the client software would try 20 times before giving up on a bad
password. Not sure why it did that, but the effect was to lockout the back end tomcat.
We need to modify the client to prevent this from happening. 

Thanks,
-Bruce

On Nov 18, 2013, at 10:29 AM, Bruce Weertman <br...@iris.washington.edu> wrote:

> I am running into an intermittent problem with Digest-Authentication. This is with tomcat 7.0.39
> 
> The issue appears to be that clients will occasionally get locked out for 5 minutes. The problem
> appears to happen with there is a combination of good password and then bad password, or the
> other way round. We have also seen the problem happen when our load balancer is not sticky. 
> 
> My understanding is that digest-auth really should not work if the load-balancer is not sticky since there need to be information
> sent from the server to the client in order to make the authentication. We have since made our load balancer sticky, hoping that 
> this would resolve the issue. 
> 
> Actually, I should make a clarification here. It’s not “clients” that are getting locked out. It is “users”. 
> 
> Once a user gets into a bad state the account gets locked out until a 5 minute period goes by. 
> 
> Looking at the tomcat source code, I see DigestAuthenticator.java line 147: 
> protected long nonceValidity = 5 * 60 * 1000;
> 
> Sorry if this sounds confused - I’m confused. I can say this. We’re seeing users get locked out for
> 5 minutes at a time. Having the load balancer not being sticky would definitely cause the problem,
> but after making them sticky, we still see the problem with at least one client program. The client
> programs are mostly non-webbrowser based.
> 
> Thanks



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