Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of cdehaudt@ebay.com designates
 216.113.172.64 as permitted sender)
DomainKey-Signature: s=ebaycorp; d=ebay.com; c=nofws; q=dns;
  h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC:
   Subject:Thread-Topic:Thread-Index:Date:Message-ID:
   References:In-Reply-To:Accept-Language:Content-Language:
   X-MS-Has-Attach:X-MS-TNEF-Correlator:user-agent:
   x-originating-ip:Content-Type:Content-ID:
   Content-Transfer-Encoding:MIME-Version:X-CFilter;
  b=K7PExF5JLKeB+n/NW1ZQ9LdYEn0rQEPLRajF3o9hG5kUzo1u0nxiHmOt
   6b0N/rezGD3ZciHSZ5Cyha/qruza77rHlapU/2Z2+jVsZ5E3gxG7Ef1pc
   rys/3EahDDVMUGmG0b+HPTlFnQLFklU+J1ge+LpcPV+lEXDfvi9vDSd9B
   o=;
From: "Dehaudt, Christophe" <cdehaudt@ebay.com>
To: Tomcat Users List <users@tomcat.apache.org>
CC: "Dehaudt, Christophe" <cdehaudt@ebay.com>
Subject: Re: multiple servers and digest authentication
Thread-Topic: multiple servers and digest authentication
Thread-Index: 
 AQHO60ML4SjOkCsSk0WU2X4+acMF8Zo5TxsAgAACyoCAAHJPgIADMwKAgALujACAAP7JgA==
Date: Mon, 2 Dec 2013 13:53:46 +0000
Message-ID: <CEC1C3FE.391FE%cdehaudt@ebay.com>
References: <CEBAE06A.38B72%cdehaudt@ebay.com> <5295C3D0.8060005@apache.org>
 <5295C627.2060109@ice-sa.com> <5296260B.30207@christopherschultz.net>
 <CEBE7CED.38F84%cdehaudt@ebay.com> <529B4AAE.6020200@christopherschultz.net>
In-Reply-To: <529B4AAE.6020200@christopherschultz.net>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.9.131030
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <BFF5CED75E6B5247B75A71E667815148@corp.ebay.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 12/1/13 6:41 AM, "Christopher Schultz" <chris@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 =3D> 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 =3D> 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 =8A. 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 =3D 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
>=3DQs1j
>-----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