AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Indeed, it seems a little bit strange and certainly you are right. I think the main reason is that it would be more complicated to maintain the system with regular security updates. It has to be a manual process. Somehow or other we need a working solution. It is also an option to fix DigestAuthenticator class in tomcat6 to split digest authentication header like it is done in tomcat7, because this is the real cause of the problem - the regular expression submitted to the split method cannot properly handle unquoted parameters at the end of the auth header line. Thank you for your constructive input. -sascha Von: Christopher Schultz [ch...@christopherschultz.net] Gesendet: Dienstag, 17. März 2015 17:10 Bis: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/17/15 11:12 AM, Rainer Jung wrote: Am 17.03.2015 um 15:40 schrieb Sascha Skorupa: Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. OK. But think twice, whether it is better to just compile mod_jk from sources or do the big update. +1 I find it hard to believe that you (or your NOC) would be willing to upgrade the OS and the web server to use an alternative solution, but not willing to upgrade to a newer version of single, specialized module for the web server. Note that you don't have to have a compiler on the target system; you just need to be able to cross-compile to that test system (or do what I do and have a spare server with identical architecture, etc. available for module builds). Updating to 2.4 will bring many interesting achievements, but just for fixing this issue quickly it would be better to update mod_jk, even if this means switching to a non-OS-provided variant. +1 Building is trivial. If you seriously plan the 2.4 update and you have a test system, I could provide you with the non-trivial workaround letting Apache set the cookie. You would need to thoroughly test this though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVCFHcAAoJEBzwKT+lPKRYOQAQAJnIlsepWBvZlO438/zwXIYM WI0X3LspAUt1v1c0JOXagL5VUdZO68/euBV7rmoKaHvo11lEH5lFQ9M91unvRWer d7AQZoTc1+VQDcnBrGDzw6M7jQqlKf2Y7Jadlj9TfNm68cwCYFhpan1Wcv/XCMpy /1Q5j/gW77AdPNpAvtFGOXZ0HPbMpkC+ZpsfFjgpOrwUBPL195xpQXM5nJLoYpAa 7uR34FCAbIIR0Glho/IHqzadxrSBq3AEVZau1uiGi3t8BjuWcOfq85bMZ0dCGdl+ Hlj6wKaTpS6AJi9By5d0xbXkqu5wBY2qFgY6wNq/cHO/Js+svPPMtME7eUZiOPAY t2dUszkzqw0JOEqTN0I1gr0cGVOhJYbHMAdCHrb15FtWACeQVHVK7ikI0GJvKMG3 8EUIW21go3ID4jHBpexMC23QZDKfDTIhzx9Ec300lxRbjkfzpTCEvu3mM36w6y7+ fsRPPkpY0KqFe25nYw/DZCMS4KeAZ5dZSQa3sQSYgpozP71UrRZJw2+cqdALj29Q Ozru/eLGLAvJuOKbXgSMIBfEQugx8vTGzE60Db7e61thMPmyHXlHqi1+zKDnODej g6kbQtNDhak+0AfI2oFbmvHGz+hN8bAJa62hA/3jDKiYphxwH2JpJW4qmcs7HI91 qRp/u8yrAe8S/UAc+x+2 =95gA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Rainer, thank you for this hint, but unfortunately, this feature is too new to be included in any current mod_jk linux package and building it from source it not an option for a production environment. Too bad because that is exactly what we need that. Christopher, your suggestion sounds interesting. Would it be an option for future releases of tomcat? Sascha -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 13. März 2015 19:24 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/13/15 12:15 PM, Rainer Jung wrote: Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and- digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Oh, good: I had missed that feature. Thanks for pointing it out! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 XROKEh5OIpcNKOPxBoof =w+jN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Hi Rainer, currently not (Apache 2.2) but it might be an option to upgrade the OS and the Apache if it leads to a solution. Regards sascha -Ursprüngliche Nachricht- Von: Rainer Jung [mailto:rainer.j...@kippdata.de] Gesendet: Dienstag, 17. März 2015 15:00 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem Hi Sascha, Am 17.03.2015 um 13:02 schrieb Sascha Skorupa: Rainer, thank you for this hint, but unfortunately, this feature is too new to be included in any current mod_jk linux package and building it from source it not an option for a production environment. Too bad because that is exactly what we need that. are you using Apache 2.4? In that case I might have an alternative recipe for you. Regards, Rainer Christopher, your suggestion sounds interesting. Would it be an option for future releases of tomcat? Sascha -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Freitag, 13. März 2015 19:24 An: Tomcat Users List Betreff: Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 3/13/15 12:15 PM, Rainer Jung wrote: Am 13.03.2015 um 16:28 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and - digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using that attribute you can let mod_jk set the cookie, if it doesn't find one already set by Tomcat. You need to also set session_cookie=JSESSIONID and session_cookie_path=/myapp where you adjust myapp to your context path. Oh, good: I had missed that feature. Thanks for pointing it out! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAytTAAoJEBzwKT+lPKRYO9EP/1NnmcKmXYwYYvtnb97dMZmz NI7GIaZYDhx1NLb7w5UFDrPNhaAvBDSvzmNxnhZPfdPcwUK93k95+KVymrpI49xh wJ7wbBlFPJcB6coK35jwp0oZnfKbUyHFZ6Qr/r4fbrd57PDqCKGLc/6YicY11nm+ 3EGCYHKe/B2orPNJvw+B5ZCm4cJFwh/VWespkAylCWbqJV1k882zG4MJEwZWgXdn FBLggaCW1N5V6LNAhKiwyrrZrcV9TY3zoMI4Dd8M8yzq8MoTbUK2g2sYZh0LNm0d 0ZbcE07uBUgO5NamNk049vSK+yx0gfHmnL1Gst/jdQ23I8876cTYNCkJKyb0/uDq x5nv2K+dYj1rDeak3j4PS35W+Z6C/SCyp8n3W2L16xtLYtDRQTYv4OTOv1oVTuA2 UueFMwnqRoJV24nLathp29RnjODK7shYce1JqShiAVXzyKSgAkWsu2J8V07txUjP 4v+E0LrWOGEimvHfrOYqdTmH+Ed6YEcttrYU2ddH1g2z4Hz9n+S+fsO2fQgLhY/S V6RluOXfAlg6+IFEtW7DW2PzXuQxOHfKfIX3dlBDGrJGoYNFdYY+uaZO6TPyp7qR UVO9BRA0Roxtpvn7TpJJjygjNXM7uac5MMeCJtA4KPd29PT0sxAnJv+NYpYJ1F35 XROKEh5OIpcNKOPxBoof =w+jN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/12/15 1:13 PM, Mark Thomas wrote: On 12/03/2015 15:20, Sascha Skorupa wrote: Hi, here: http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication the same problem is described and the recommended solution is to use sticky load balancing. But, the problem in a tomcat cluster is that the session ID is generated after a successful authentication. The first http response (401 with Authentication Header) does not contain a session ID. How should sticky load balancing be configured or how to enforce session id generation before authentication? Most load-balancers have various options for doing this that don't depend on the back-end server at all. Perhaps an option in Tomcat that will force the creation of a session when a DIGEST authentication is requested might be useful. This would tie e.g. mod_jk to the proper back-end server. I'm not sure how this could be done using mod_jk without such a feature, or changes to mod_jk itself to annotate the request with the chosen worker, which could then be converted into a cookie in order to keep the node-hint associated with the client. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVAwIvAAoJEBzwKT+lPKRYOc4P/2+nCQm+qwhJpz5hxEFaxebx Y34D5ZF9D4OEdGeaRKNj+mYfDPHDpkbI2Ks3bewf1esnIlA96F4oXPdkXMc2Gn/F 1ETNN78g5ulquya/AYmNjVq1fAtjoaiiisKpv5iM0DJIVA0EdH3T8yUoA9t4MwPc ndnt89eFfCeFi3FcJCP6EE1TFib+qWsBsAAwSP1J6JttzCDHviDjLt4aTABwBhXf AAPzD2kLZm69FjphNOLTqaFr0Ec8+uSCGjK+UuC8AgaXYScnxBg92Y80lgqPV77m 7A6TOIVx1O8e1/6Wj1JCk4YrTrjB+90nShkATgnXBy4/DO/jEtFP7QyRovCYbuwf 9kUdl/6IovpR4j4OyYQ8EUPQqXeT3fpKZDk4XiW3iqdRX+zSyBvi95Igd+H9QfEH gK1cMmeXQEdEY0XlgXU82iVNyzbl+JWma8QswiSnXEdYdxPUTKuaZkpx2W/757ID GFlYa87tbHQbfbSnBAx5SqaoIVKqZaob7fnVkD32b0uiaCqw7nxhuB8q/QeiY9e8 8lUoTrccj5Uo+5liBp5/0ztSjSkdIZmUQdLnGhaGDBA9t1zNeyOfbNSXQjHKeEJf l/tl7GNgQ+56pGrlwmuJLPQRTyjwcx+6B9SmpUhJly4YaxMS13Tk77azwVnjCEV4 RQu1uvmH9wOhNCocyyAe =TebI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Hi,
here:
http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication
the same problem is described and the recommended solution is to use sticky
load balancing. But, the problem in a tomcat cluster is that the session ID is
generated after a successful authentication. The first http response (401 with
Authentication Header) does not contain a session ID.
How should sticky load balancing be configured or how to enforce session id
generation before authentication?
Regards
Olschi
Von: Sascha Skorupa
Gesendet: Mittwoch, 4. März 2015 16:21
An: 'users@tomcat.apache.org'
Cc: Sebastian Olscher
Betreff: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest
Authentication problem
Hi,
because of changes in the HTTP digest implementation within the JDK 8
(https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate
from tomcat 6 to 7.
The problem is that we have a tomcat cluster (several tomcats behind an
apache/modjk server) and we cannot guarantee that both HTTP requests resulting
from the digest authentication are sent to the same tomcat instance. In Tomcat
6 it was no problem because nonces were not cached or rather unknown nonces did
not force a re-authentication like it is done in the DigestAuthenticator of
Tomcat 7:
if (info == null) {
// Nonce is valid but not in cache. It must have dropped out
// of the cache - force a re-authentication
nonceStale = true;
}
Some clients have the problem that the second 401 response to the request with
authorization header leads to an authentication failure although the
credentials are correct. Other clients like e.g. JMeter keep trying to send
authorisation header, if stale is true, until a HTTP 200 is responded.
So, what is the recommendation here? How to use Digest authentication within
tomcat clusters if nonces are cached in a map within DigestAuthenticator?
Best regards
Sascha
Re: AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
On 12/03/2015 15:20, Sascha Skorupa wrote:
Hi,
here:
http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication
the same problem is described and the recommended solution is to use sticky
load balancing. But, the problem in a tomcat cluster is that the session ID
is generated after a successful authentication. The first http response (401
with Authentication Header) does not contain a session ID.
How should sticky load balancing be configured or how to enforce session id
generation before authentication?
Most load-balancers have various options for doing this that don't
depend on the back-end server at all.
Mark
Regards
Olschi
Von: Sascha Skorupa
Gesendet: Mittwoch, 4. März 2015 16:21
An: 'users@tomcat.apache.org'
Cc: Sebastian Olscher
Betreff: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest
Authentication problem
Hi,
because of changes in the HTTP digest implementation within the JDK 8
(https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate
from tomcat 6 to 7.
The problem is that we have a tomcat cluster (several tomcats behind an
apache/modjk server) and we cannot guarantee that both HTTP requests
resulting from the digest authentication are sent to the same tomcat
instance. In Tomcat 6 it was no problem because nonces were not cached or
rather unknown nonces did not force a re-authentication like it is done in
the DigestAuthenticator of Tomcat 7:
if (info == null) {
// Nonce is valid but not in cache. It must have dropped
out
// of the cache - force a re-authentication
nonceStale = true;
}
Some clients have the problem that the second 401 response to the request
with authorization header leads to an authentication failure although the
credentials are correct. Other clients like e.g. JMeter keep trying to send
authorisation header, if stale is true, until a HTTP 200 is responded.
So, what is the recommendation here? How to use Digest authentication within
tomcat clusters if nonces are cached in a map within DigestAuthenticator?
Best regards
Sascha
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Sascha, you can configure source address stickyness as well as
destination address stickyness, both will provide the same result
which will work for you.
2015-03-12 18:13 GMT+01:00 Mark Thomas ma...@apache.org:
On 12/03/2015 15:20, Sascha Skorupa wrote:
Hi,
here:
http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication
the same problem is described and the recommended solution is to use sticky
load balancing. But, the problem in a tomcat cluster is that the session ID
is generated after a successful authentication. The first http response (401
with Authentication Header) does not contain a session ID.
How should sticky load balancing be configured or how to enforce session id
generation before authentication?
Most load-balancers have various options for doing this that don't
depend on the back-end server at all.
Mark
Regards
Olschi
Von: Sascha Skorupa
Gesendet: Mittwoch, 4. März 2015 16:21
An: 'users@tomcat.apache.org'
Cc: Sebastian Olscher
Betreff: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest
Authentication problem
Hi,
because of changes in the HTTP digest implementation within the JDK 8
(https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate
from tomcat 6 to 7.
The problem is that we have a tomcat cluster (several tomcats behind an
apache/modjk server) and we cannot guarantee that both HTTP requests
resulting from the digest authentication are sent to the same tomcat
instance. In Tomcat 6 it was no problem because nonces were not cached or
rather unknown nonces did not force a re-authentication like it is done in
the DigestAuthenticator of Tomcat 7:
if (info == null) {
// Nonce is valid but not in cache. It must have dropped
out
// of the cache - force a re-authentication
nonceStale = true;
}
Some clients have the problem that the second 401 response to the request
with authorization header leads to an authentication failure although the
credentials are correct. Other clients like e.g. JMeter keep trying to send
authorisation header, if stale is true, until a HTTP 200 is responded.
So, what is the recommendation here? How to use Digest authentication within
tomcat clusters if nonces are cached in a map within DigestAuthenticator?
Best regards
Sascha
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
