tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: multiple servers and digest authentication
Date Sun, 01 Dec 2013 14:41:50 GMT
Hash: SHA256


On 11/29/13, 8:55 PM, Dehaudt, Christophe wrote:
> 1/ Sticky session : yes, that is the way I have currently set my
> load balancer. But there is a drawback when the client is
> contineoulsy using the service => because it will never been load
> balanced again.

When the sticky cookie expires, the client can be re-balanced.

> The worst is when one of the server is stopped and restarted => all
> the clients will be redistributed to the still alive servers, And
> when the server is restarted, it will not picked up any load

It will pick-up new load.

> To work-around this problem, with sticky session on , I have
> patched my client to clear the sticky cookie every X minutes. That
> enforces the load balancer to give me the less used servers
> (possibly the one that have been restarted)

This should be configurable on the server and/or the lb. You shouldn't
have to modify the client.

> 2/ front-end load balancer solution: my configuration is with an F5
> load balancer (citrix).

I'm not sure what that means. F5 and Citrix are competitors AFAIK.

> From what I understand, the question is : can we configure the F5
> to manage the nonce and then delegate the authentication to the
> servers (tomcat)- .

That's not going to work unless you tell the (Tomcat) server that the
(F5) client is trusted. If the client is trusted (as far as Tomcat is
concerned), then there is no need for authentication. Tomcat will not
implement such capabilities. You'll need to do that yourself.

> Any idea if this is feasible from F5/tomcat point of views?

I don't believe you can have the F5 manage any part of the
authentication. But you can use (expiring!) sticky load-balancing.
I've never used an F5 but I suspect that you can use a combination of
lb-generated cookie + server-generated cookie to achieve a "unified
stickiness". What you want is the following:

1. 2-step authentication has both steps going to the same server (can
use F5's cookie for stickiness)

2. Subsequent authenticated requests go to that same server (can use
Tomcat's cookie for stickiness)

3. All stickiness expires when the user's authenticated session
expires. Since HTTP-DIGEST authentication does not have a standard way
to de-authenticate a client, you'll have to figure out when this
happens. I would use the invalidation of the session cookie to trigger
a reset of the F5's stickiness cookie. I'm not sure how to actually do
that with an F5.

- -chris
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message