You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2013/12/01 15:41:50 UTC
Re: multiple servers and digest authentication
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Christophe,
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSm0qrAAoJEBzwKT+lPKRY7UIQALorBonbQ6XeXPEK3q0G2RrU
i34F82XlFXVwlGuupK4ROxaDYsPa+HJgSC3WH5J/+q5MjX2s8GfgJwp7WmCYNkNr
4vokKOHxwkWy8km/iEwNLbFu0SWJUEFNpfsgCwBvlKuiDr7uIZDGqOSDQlCY4p7G
U0eql7Pi/L9hg45IiNUnYpqYij2/bsXNzi8kbLd7u84GOrn6UY6jQScsIGVxbNjV
hvPck4Srmsh4OqicL/o98u7N9vbu7x+/leoSCkt2d6cPtQPhd2Pp0oOvmy0NX/j8
+R+JXapT7J6dT2jXI6bbUqJlP+5c2xRZoN79Rw3291ZHLBJ9+89XYazLcEdXyPVO
JVUcJOwRvPLAF5vXwWyIkQGz9aeypfYWGQm5D2CK8A942Fhfnn4gGYn+LfQi3I/b
SMRMTKQZpwB1jC4iEfbPJS682V2swHOySUzcSKXAnnO2BfvraA2/vGD/IW3FLcfl
U4oU6teQ0NTIZTN6oCCpj4fzniQXhjKWAhZRL7jYzDoiPAGR5FdmGDBfCgky6+z/
fu4xSopN5a0otiX5IXizqn4zemewy779Shl6OiI6dbGGDIZ0nNlMPdfkauGz+sP5
cWG+COKG1lSajSPq1CWTWhYHLJ1+qeaUqVWvzCik9Z/NGhFmQf5KiPMCsPkREVs/
bpHvDjAQhBPjjyEDf4nV
=Qs1j
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple servers and digest authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Christophe,
On 12/2/13, 8:53 AM, Dehaudt, Christophe wrote:
> On 11/29/13, 8:55 PM, Dehaudt, Christophe wrote:
>> 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.
>
> I believe I already do 3 (clearing the LB cookie, every X mn), but
> this solution is client side, meaning everybody must be a good
> citizen. I would prefer a solution that enforces the policy = LB or
> server side
Just set the expiration-date of the cookie (on the server) to be 2
minutes?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSnLVOAAoJEBzwKT+lPKRYC8IP/3icAeE5gDbGniNz5sstQ0Td
Yo8ZccqHejVBHH7lqtTkCzjQZGYSFtLJXb1BzV+HvHXtluprIkT4ASFJr51sXwN+
GoeKjOABTC+ThVb8209XZSxg7CnEgEsP14W9HiOCdu3Vv4YNALM6cgokc/WTQYyq
Zqn/MipE2eKjxN5C9K4PeYn6YmNxEk0G9JKfNGDWO/sjBrW0q4/Z4ozcUBg9kR1X
qbf+9Pbrdk8uXzEtrvmPTs0qGp3DcjA//4d/DGCbmCWJwV6luwblvgw11++0qmz0
zjkX+DnyipP9tliE+Rl2Y7M7fdwr4hGAVweyAazL6V1q/fXsik2BeCtZJVq3QE23
H3WhZQIefR9j7+mF7qdVNAJN/lZVIynuKf32sReQHjg5nGFCd/Dp79TZdSXL6yvQ
f0Sb4NaQvBzQD03Nv4wx8KLTaQAQSc0Y5bKuZefCsjdxQbCU6HQiMn0hb7xV5SXi
cOfbf3a/6VD7IlxxqpRV2JDZ63VqYb2I9zKXydUL5hx/dazcChkSpGKFigQttifN
StNDwgIWOs4YNzPyLaCEK1rDGRGtkAN2TskfRdR2eXRC/YHsLtHmXJcbK3tUt6ny
/20uA+UxTgkjzTBd8ij6RapNwCtMeE8cB09rrxp4YiOIBT5Bj91ZQP0xg9b8/mYq
6/yl8K9R/SUZ1OGb1RxK
=hmOu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: multiple servers and digest authentication
Posted by "Dehaudt, Christophe" <cd...@ebay.com>.
On 12/1/13 6:41 AM, "Christopher Schultz" <ch...@christopherschultz.net>
wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Christophe,
>
>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.
Yes the cookie has an expiration time when it is come for 2mn. But each
time client is calling again the service (sending back the cookie), it
will receive back the cookie with a renewed expiration. So, if the client
has a frequency greater than 1 call every 2mn, cookie is always valid, and
will stay stick to the same server .. Hence my quote
>
>> 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.
If the cookie expires Š. But it might not
>
>> 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.
Sorry. Yes my load balancer is Citrix NetScaler 9.3 (not F5)
>
>> 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.
I believe I already do 3 (clearing the LB cookie, every X mn), but this
solution is client side, meaning everybody must be a good citizen. I would
prefere a solution that enforces the policy = LB or server side
>
>- -chris
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.15 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQIcBAEBCAAGBQJSm0qrAAoJEBzwKT+lPKRY7UIQALorBonbQ6XeXPEK3q0G2RrU
>i34F82XlFXVwlGuupK4ROxaDYsPa+HJgSC3WH5J/+q5MjX2s8GfgJwp7WmCYNkNr
>4vokKOHxwkWy8km/iEwNLbFu0SWJUEFNpfsgCwBvlKuiDr7uIZDGqOSDQlCY4p7G
>U0eql7Pi/L9hg45IiNUnYpqYij2/bsXNzi8kbLd7u84GOrn6UY6jQScsIGVxbNjV
>hvPck4Srmsh4OqicL/o98u7N9vbu7x+/leoSCkt2d6cPtQPhd2Pp0oOvmy0NX/j8
>+R+JXapT7J6dT2jXI6bbUqJlP+5c2xRZoN79Rw3291ZHLBJ9+89XYazLcEdXyPVO
>JVUcJOwRvPLAF5vXwWyIkQGz9aeypfYWGQm5D2CK8A942Fhfnn4gGYn+LfQi3I/b
>SMRMTKQZpwB1jC4iEfbPJS682V2swHOySUzcSKXAnnO2BfvraA2/vGD/IW3FLcfl
>U4oU6teQ0NTIZTN6oCCpj4fzniQXhjKWAhZRL7jYzDoiPAGR5FdmGDBfCgky6+z/
>fu4xSopN5a0otiX5IXizqn4zemewy779Shl6OiI6dbGGDIZ0nNlMPdfkauGz+sP5
>cWG+COKG1lSajSPq1CWTWhYHLJ1+qeaUqVWvzCik9Z/NGhFmQf5KiPMCsPkREVs/
>bpHvDjAQhBPjjyEDf4nV
>=Qs1j
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org