You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Dehaudt, Christophe" <cd...@ebay.com> on 2013/11/27 08:34:03 UTC
multiple servers and digest authentication
Hi,
To spread the load, my application is installed on several servers, each of them managed by Tomcat (7.0.26).
On top on that, a load balancer ensures the traffic is correctly distributed evenly.
The tomcat configuration is set with Digest authentification.
The problem I'm facing is that the digest authentication looks to work fine for one single server , but for with multiple.
Indeed, when a specific server of the pool is receiving the request and returns 401 + the nonce,
this same server must receive the second request (with the authentication) to get a success.
If another server of the pool is receiving the second request, it will be not able validate the user/pass because the nonce does not belong to it.
Is there a way to share the nonce between servers so they can act as one?
I would like to get your advices , how to make a multiple server deployment running with Http digest.
Thanks,
Xtof
RE: multiple servers and digest authentication
Posted by Martin Gainty <mg...@hotmail.com>.
> From: cdehaudt@ebay.com
> To: users@tomcat.apache.org
> CC: cdehaudt@ebay.com
> Subject: Re: multiple servers and digest authentication
> Date: Sat, 30 Nov 2013 01:55:32 +0000
>
> Hi,
>
> Thanks for your answers:
>
> 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.
> 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
>
> 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)
>
> 2/ front-end load balancer solution: my configuration is with an F5 load
> balancer (citrix). 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)- . It will require:
> F5 to manage the nonce (will send back the 401 when nonce not valid) but
MG> here is the XSD element definition for noonce using wss4j
MG>xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
MG><!-- KANonce -->
<ObjectProvider qualifiedName="xenc:KA-Nonce">
<BuilderClass className="org.opensaml.xml.encryption.impl.KANonceBuilder" />
<MarshallingClass className="org.opensaml.xml.schema.impl.XSBase64BinaryMarshaller" />
<UnmarshallingClass className="org.opensaml.xml.schema.impl.XSBase64BinaryUnmarshaller" />
</ObjectProvider>
MG>so How would F5 build out a noonce such as
<EncryptedData>
<EncryptionMethod Algorithm="Example:Block/Alg"
<KeySize>80</KeySize>
</EncryptionMethod>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<AgreementMethod Algorithm="example:Agreement/Algorithm">
<KA-Nonce>Zm9v</KA-Nonce>
<ds:DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha1"/>
<OriginatorKeyInfo>
<ds:KeyValue>....</ds:KeyValue>
</OriginatorKeyInfo>
<RecipientKeyInfo>
<ds:KeyValue>....</ds:KeyValue>
</RecipientKeyInfo>
</AgreementMethod>
</ds:KeyInfo>
<CipherData>...</CipherData>
MG>?
> not verify the user credential and pass that to servers
>
> Servers (tomcat) to not check the nonce but check the credential. I have
> read the description of tomcatAuthentication flag from André's link, but
> I'm not sure it does what I expect
>
> Any idea if this is feasible from F5/tomcat point of views?
> Any other suggestions? ;)
>
> Thanks,
>
> Xtof
>
> On 11/27/13 9:04 AM, "Christopher Schultz" <ch...@christopherschultz.net>
> wrote:
>
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA256
> >
> >André,
> >
> >On 11/27/13, 5:15 AM, André Warnier wrote:
> >> Mark Thomas wrote:
> >>> On 27/11/2013 07:34, Dehaudt, Christophe wrote:
> >>>> Is there a way to share the nonce between servers so they can
> >>>> act as one?
> >>>
> >>> No. You'd need to customise the DigestAuthenticator to do that.
> >>>
> >>>> I would like to get your advices , how to make a multiple
> >>>> server deployment running with Http digest.
> >>>
> >>> Use sticky load-balancing.
> >>>
> >>
> >> Or do the authentication at the front-end load-balancer level, and
> >> set Tomcat's authentication to accept what the front-end says ?
> >> (E.g.
> >>
> >>https://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html#Standard_Impleme
> >>ntations
> >>
> >> #tomcatAuthentication)
> >
> >While it is popular to do so, I don't think anyone really uses httpd
> >for industrial-strength load-balancing. Can an F5 do authentication
> >(and forward it to Tomcat?). I suspect not in any way that would work
> >well with the back-end application.
>
>
> ---------------------------------------------------------------------
> 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
Re: multiple servers and digest authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 "Dehaudt, Christophe" <cd...@ebay.com>.
Hi,
Thanks for your answers:
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.
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
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)
2/ front-end load balancer solution: my configuration is with an F5 load
balancer (citrix). 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)- . It will require:
F5 to manage the nonce (will send back the 401 when nonce not valid) but
not verify the user credential and pass that to servers
Servers (tomcat) to not check the nonce but check the credential. I have
read the description of tomcatAuthentication flag from André's link, but
I'm not sure it does what I expect
Any idea if this is feasible from F5/tomcat point of views?
Any other suggestions? ;)
Thanks,
Xtof
On 11/27/13 9:04 AM, "Christopher Schultz" <ch...@christopherschultz.net>
wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>André,
>
>On 11/27/13, 5:15 AM, André Warnier wrote:
>> Mark Thomas wrote:
>>> On 27/11/2013 07:34, Dehaudt, Christophe wrote:
>>>> Is there a way to share the nonce between servers so they can
>>>> act as one?
>>>
>>> No. You'd need to customise the DigestAuthenticator to do that.
>>>
>>>> I would like to get your advices , how to make a multiple
>>>> server deployment running with Http digest.
>>>
>>> Use sticky load-balancing.
>>>
>>
>> Or do the authentication at the front-end load-balancer level, and
>> set Tomcat's authentication to accept what the front-end says ?
>> (E.g.
>>
>>https://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html#Standard_Impleme
>>ntations
>>
>> #tomcatAuthentication)
>
>While it is popular to do so, I don't think anyone really uses httpd
>for industrial-strength load-balancing. Can an F5 do authentication
>(and forward it to Tomcat?). I suspect not in any way that would work
>well with the back-end application.
---------------------------------------------------------------------
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
André,
On 11/27/13, 5:15 AM, André Warnier wrote:
> Mark Thomas wrote:
>> On 27/11/2013 07:34, Dehaudt, Christophe wrote:
>>> Is there a way to share the nonce between servers so they can
>>> act as one?
>>
>> No. You'd need to customise the DigestAuthenticator to do that.
>>
>>> I would like to get your advices , how to make a multiple
>>> server deployment running with Http digest.
>>
>> Use sticky load-balancing.
>>
>
> Or do the authentication at the front-end load-balancer level, and
> set Tomcat's authentication to accept what the front-end says ?
> (E.g.
> https://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html#Standard_Implementations
>
> #tomcatAuthentication)
While it is popular to do so, I don't think anyone really uses httpd
for industrial-strength load-balancing. Can an F5 do authentication
(and forward it to Tomcat?). I suspect not in any way that would work
well with the back-end application.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSliYKAAoJEBzwKT+lPKRYOboP/0G0LYOQp730gk4yLS8quDN8
Z1H0NsjZgvo+EiRWTTwuk2yI7UoAgvEsyx+0AuyPL13Oe4ifUsPxTJQG83N76eBQ
LGqPQBsEbuVyZ9dlI7OtK0M17BVywUp6Ep4XHWFnlwdvBmK+ufYcpQzIP2HrtbRu
3TSHK7JUfrvm4fFJfwxzoY08YbgDIoCsflwt3NAgqg5Mgp+io785XjmKFnnC9B4/
ymIwFGAntlveWur83/4m2M2tVRC/tZMUbGqdlTPbL8/K7IGDp4sVRuZ0QKIl0Y4C
0NSHe/CG1MI5910FV4n9EYwekbrYP8+zF3MLgqTx1r4CqGRXisWqCynni4xXwiVe
+kAWlvJlk74/H/umn63X0CRQi7CB41IoK2Ee9wpBD9EvDp5a19gQAyyrdVx8FX7R
tfmXpoGYHp2yXku3/aAsaO9aQKI/74mgl4ijptnBwTLsf1X5kRtWguyXarffJ4Kr
uAoumSvSsCOhaNs9Vtwir6189LzGR9cFI1KFqB2xSZbXslG01OPp3Ro+mAAI1Rbi
mmP5b8AfowWmBeiis21Bntz3W8RcehTN4+v2OWXEE7ABoqyteYmaPE+5SnDQD+fC
WEJpldfxArdzZYp6TSCvVKUmgGRrq2w408RfEoz+nu6myEQZ0op4j9CVw7xm9mrv
/o63n2ZBKbzOMia93sFq
=Wecd
-----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 André Warnier <aw...@ice-sa.com>.
Mark Thomas wrote:
> On 27/11/2013 07:34, Dehaudt, Christophe wrote:
>> Is there a way to share the nonce between servers so they can act as one?
>
> No. You'd need to customise the DigestAuthenticator to do that.
>
>> I would like to get your advices , how to make a multiple server deployment running with Http digest.
>
> Use sticky load-balancing.
>
Or do the authentication at the front-end load-balancer level, and set Tomcat's
authentication to accept what the front-end says ?
(E.g. https://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html#Standard_Implementations
#tomcatAuthentication)
---------------------------------------------------------------------
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 Mark Thomas <ma...@apache.org>.
On 27/11/2013 07:34, Dehaudt, Christophe wrote:
> Is there a way to share the nonce between servers so they can act as one?
No. You'd need to customise the DigestAuthenticator to do that.
> I would like to get your advices , how to make a multiple server deployment running with Http digest.
Use sticky load-balancing.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org