Hello, With debugging I finally found out why Jersey and Tomcat doesn't play well with digest authentication.
If a nonce got stale and tomcat issues a new authentication request. Jersey answers this request and responds with a valid header in terms of the HTTP digest specification. The nonce-count field isn’t set to 1 by Jersey in this case. Instead the old value is increased. This new value isn't accepted by tomcat (DigestInfo class, isNonceCountValid()). Tomcat forces this value to be 0 on new authentication. As the HTTP Digest authentication isn't clean at this point I strongly recommend to change tomcat sources and allow nonces with a random value on authentication. This could be achieved if the nonce-count is read from the client request on authentication. - Andreas > -----Ursprüngliche Nachricht----- > Von: Kehlenbach, Andreas [mailto:andreas.kehlenb...@prostep.com] > Gesendet: Freitag, 9. Januar 2015 12:00 > An: Tomcat Users List > Betreff: [bulk]: Re: Is tomcat UserDatabaseRealm buggy? > > Hello Chris, > > Currently I've attached tomcat sources to my sample application. > The following I found out: > > 1) The problem occurs only if the nonce timed out. > 1.1) After the nonce timed out, tomcat sends a new nonce, which the client > correctly respond to. The new response contains the last send (new) nonce, > an increased nonce count and the correct opaque. > > in DigestAuthenticator. authenticate(Request request, HttpServletResponse > response, LoginConfig config) a new DigestInfo object is build. This object > then contains nonceStale = true. From my point of view this is a bug, because > after a timeout a valid new nonce should be sent to the client. > > - Andreas > > PS: Please do not use Jersey 1.18.2, because the client also contains a bug. > If > the nonce timed out, the old and new authorization header is sent to tomcat. > Thus, two authorization headers are transmitted and tomcat could not > handle this. If you want to use this client, I could provide you a fix for > this. > > > -----Ursprüngliche Nachricht----- > > Von: Kehlenbach, Andreas [mailto:andreas.kehlenb...@prostep.com] > > Gesendet: Dienstag, 23. Dezember 2014 08:33 > > An: Tomcat Users List > > Betreff: [bulk]: AW: [bulk]: Re: Is tomcat UserDatabaseRealm buggy? > > > > Hello Chris, > > > > Long story short: I had no time in past, but now I created a small sample. > > Attached you could find two archives. > > projects.zip: contains two eclipse projects (client and server) > > tomcat- config.zip contains three xmls which I copied into conf/ folder of > tomcat. > > > > You could export the war file from within eclipse or just use the pre- > > exported war file with the tomcat.zip. > > The client project contains a ClientTest-class with a unit test. This > > test just fails if one is no longer "logged in". There should be a 401 > > at some point in time in access.log of tomcat. > > > > As I'm unable to attach stuff larger than 1MB you must manually add > > all needed jersey jars into projects of attached archive. > > MyClient\lib\jersey-client-1.18.2.jar > > MyClient\lib\jersey-core-1.18.2.jar > > MyClient\lib\junit-4.10.jar > > > > and > > > > MyWebApplication\WebContent\WEB-INF\lib\jersey-core-1.18.2.jar > > MyWebApplication\WebContent\WEB-INF\lib\jersey-server-1.18.2.jar > > MyWebApplication\WebContent\WEB-INF\lib\jersey-servlet-1.18.2.jar > > > > Hope it helps and merry christmas, > > Andreas > > > > > -----Ursprüngliche Nachricht----- > > > Von: Christopher Schultz [mailto:ch...@christopherschultz.net] > > > Gesendet: Mittwoch, 26. November 2014 17:20 > > > An: Tomcat Users List > > > Betreff: [bulk]: Re: Is tomcat UserDatabaseRealm buggy? > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > Andreas, > > > > > > On 11/26/14 5:42 AM, Kehlenbach, Andreas wrote: > > > > I think I found the following bug in tomcat 7/8 with the following > > > > setup: > > > > > > > > We use tomcat 7.0.42 (but I tried 7.0.55 and 8.0.15 without > > > > success) and deployed a web service with jersey 1.18.2. > > > > Additionally we set up HTTP authentication. In our case DIGEST > > > > authentication, but I tried BASIC authentication the observed > > > > behavior is the same. We have a web service with login and logout > > > > methods, as well as some other methods which could only be invoked > > > > if a login request was made previously. Authentication works fine, > > > > till some point in time. At this point the client receives a HTTP > > > > response 401 Unauthorized. I double checked that the client sends > > > > correct credentials and nonce values. On server side I enabled > > > > logging (see attached log file). The log shows two web service > > > > calls, the first one returns successfully the last one reports the > > > > 401 error. As one could see in line 12 and 13 FEIN: Calling > > > > authenticate() Nov 18, 2014 2:58:25 PM > > > > org.apache.catalina.realm.RealmBase authenticate Tomcat delegates > > > > the authentication request to RealmBase class logs some stuff and > > > > returns with FEIN: Successfully passed all security constraints > > > > > > > > But in case of my error just these three lines are logged: FEIN: > > > > Calling authenticate() Nov 18, 2014 2:58:25 PM > > > > org.apache.catalina.authenticator.AuthenticatorBase invoke FEIN: > > > > Failed authenticate() test > > > > > > > > My server.xml is as follows: <… <Engine name="Catalina" > > > > defaultHost="localhost"> <Realm > > > > className="org.apache.catalina.realm.LockOutRealm"> <Realm > > > > className="org.apache.catalina.realm.UserDatabaseRealm" > > > > resourceName="UserDatabase" digest="md5"/> </Realm> > > > > > > > > <Host name="localhost" appBase="webapps" unpackWARs="true" > > > > autoDeploy="true" deployOnStartup="true"> > > > > > > > > <Valve className="org.apache.catalina.valves.AccessLogValve" > > > > directory="logs" prefix="localhost_access_log." suffix=".txt" > > > > pattern="%h %l %u %t "%r" %s %b" /> > > > > > > > > </Host> </Engine> <… > > > > > > > > I also tried to remove the LockOutRealm, but without success. As > > > > far as I understand with this setup class > > > > org.apache.catalina.realm.CombinedRealm.java is invoked to handle > > > > authentication. If I further understand correctly, then method > > > > authenticate(String username, String clientDigest,__String nonce, > > > > String nc, String cnonce, String qop,__String realmName, String > > > > md5a2) is also invoked. This method iterates over all configured > > > > Realms. It seems to me that, in case of the 401 error, the list of > > > > realms (Line 51) is empty and thus authentication fails. > > > > > > > > The error only occurs after many calls to the webservice. I was > > > > unable to identify any pattern, but it seems related to the nonce > > > > timeout, somehow. Could one verify this bug? > > > > > > What is the nonce timeout? > > > > > > Note that HTTP BASIC authentication does not use nonces, so the > > > nonce timeout wouldn't be the cause under those circumstances. > > > > > > How did you switch testing from HTTP DIGEST to HTTP BASIC > > authentication? > > > The stored credentials are of course incompatible. If you created a > > > small test case, can you share it with us? > > > > > > - -chris > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1 > > > Comment: GPGTools - http://gpgtools.org > > > > > > > > > iQIcBAEBCAAGBQJUdf2pAAoJEBzwKT+lPKRYYa0P/1lxVAmXeDshnYP47zSnyk > > > hj > > > > wv5z86sX57H480VdYQLIIrTwj9KOa6Wifgd/YkC6fUihLNIa+kOe0Jhoq6+K/IIA > > > > > > hh9ZHu/qVKUHOsuef5sYD15CWX/VDEkJUyy4G/qvSB1u0dM5vGUkWggZVvn > > > 5kwRG > > > > > > 4V0CIg4M4bNAdki3M8ZYKp8fmD5qzYFnfmjJOKwvGiFk4nJjUZG0crVbQC69cy > > > eC > > > > > > 5/7tnzswV6dPwyJdBj0b/yiMx0h58mt0BSKz/VNsukxa2WbP0P9csP7mA9gleF > > > UB > > > > > > OQdupQ6KE5t8lQBHogHJ7QvjlOJT0Tesqn+NUbNuK8cAmntEg8HQc3b/Erqdly > > > 7G > > > > > > GMIx9dhz381RyRlZbBbvwShVc9PK8H5klDfPlwWAQzXG55+iqSx0LS2yV4X+aA > > > ht > > > > dxuE/Jc0gZRcb/s2KeUhNGR//Me1GPHStCl3nGxDMczdriEE0/Af+r6tvtXlwd0 > > > W > > > > > > 5SdVO1r3oar5e+aPBQMBqdmw47MyGx+vCdjY4jeuuoBm3XY4V2VJLrpZm993 > > > PwTV > > > > > > HgTqgREvgGzDgYkHy4Mm5Fus6YCw4GWWHjVJeff5DBezXigSBcbKtLWK4HoI1 > > > zLA > > > > > > 5k7Gm0liagpPsxovlt+OzgQ/kHqSE7qgTHgAWF8CRthOv4U8y4PJuZjPdvVeX9iE > > > oTrAPaf7gZymwtORZm1J > > > =83X2 > > > -----END PGP SIGNATURE----- > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > __________________________________________________________ > > ______________ > > PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt > > HR: Amtsgericht Darmstadt, HRB 8383 > > Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz > > Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz) > > > __________________________________________________________ > > ______________ > __________________________________________________________ > ______________ > PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt > HR: Amtsgericht Darmstadt, HRB 8383 > Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz > Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz) > __________________________________________________________ > ______________ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org ________________________________________________________________________ PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt HR: Amtsgericht Darmstadt, HRB 8383 Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz) ________________________________________________________________________
