You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Kehlenbach, Andreas" <An...@PROSTEP.com> on 2014/11/26 11:42:58 UTC

Is tomcat UserDatabaseRealm buggy?

Hello,

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 &quot;%r&quot; %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?

Best Regards,
Andreas

___________________________________________________________________
Andreas Kehlenbach
Software Engineer, SWD

PROSTEP AG
Dolivostrasse 11, D-64293 Darmstadt

Tel.: +49 6151 9287 332
Fax: +49 6151 9287 326

Email: andreas.kehlenbach@prostep.com
_____________________________________________________________________


________________________________________________________________________
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)
________________________________________________________________________

AW: [bulk]: Re: Is tomcat UserDatabaseRealm buggy?

Posted by "Kehlenbach, Andreas" <An...@PROSTEP.com>.
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:chris@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 &quot;%r&quot; %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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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)
________________________________________________________________________

Re: AW: [bulk]: Re: Is tomcat UserDatabaseRealm buggy?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Andreas,

On 11/26/14 11:26 AM, Kehlenbach, Andreas wrote:
> Yes I know that BASIC authentication doesn't use nonces, thus I
> don't think that this is the root cause. Just forget about the
> nonce timout.

Umm... you suggested that it was the cause. Okay, I'm happy to drop it.

> For full information: I played around with the timeout and used 
> values of 1, 5, 20 minutes.
> 
> But as I discovered that also the 401 appears with BASIC 
> authentication I would suggest to test with this.

There are many reasons to get a 401, so it's possible that these
issues are not related as all, but I suspect there is some kind of
workflow problem going on. AFAIK, Tomcat does the same thing with each
request when it comes to authentication. Are you sure that your
clients do the same?

> I reconfigured tomcat, because the configuration differs. That’s
> what I did to test both cases.
> 
> I hope I could create a small test case tomorrow.

Okay, we'll have a look.

When the service stops working (i.e. returns a 401), does it return
401 for all clients at once, or just for a single client in
particular? If just a single one, is there any timing information you
can give us (like "after 5 minutes in all cases, clients start getting
401s instead of 200s")?

- -chris

>> -----Ursprüngliche Nachricht----- Von: Christopher Schultz
>> [mailto:chris@christopherschultz.net] Gesendet: Mittwoch, 26.
>> November 2014 17:20 An: Tomcat Users List Betreff: [bulk]: Re: Is
>> tomcat UserDatabaseRealm buggy?
>> 
> 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 &quot;%r&quot; %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
>> 
>> ---------------------------------------------------------------------
>>
>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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) 
> ________________________________________________________________________
>
>  
> ---------------------------------------------------------------------
>
> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUdgHLAAoJEBzwKT+lPKRYJj4P/25ga6UDix++Wm+EnJX4Zdu3
4S8lcqc4MqbiaVTDGPLctA0FlZSURJZdDaNXRV/GXXvh2OQ237RNvTwoTt51+Vi7
DyYye4rkZinmY17opLLQ9ukFtS/q1oRZa34eWUdBrGzI9aD0+2CQFlK2fYxwA8Lw
FAdslGkySfGoRhL5vFHmhWfp5BUewnuMTLHepgTc7FA59Dq33eOoWIjXBqdZGGge
whCfVJ6v8BOG3bUH4tG6iy5dN3nBG6tus+V19bmLSq4BLTN6mo4vgLBI3msxsqDR
100hIUJYW6bIyqjovtkMUQvBGIVeD/eJwm2l+qbs9EQQ8b6G2MhaD2+Qux3rpmaO
nVu/VDsdwTfdO59YatnI4mGqf9HIcsOnNjAWYwesYdWNOwPx1o0jZ0viUq5EjArI
WasldX2oRDvRUN2tNG56f+mAm3z9VIbLDHSHbVqT2es93mblqsbbURbn/rjq9sRW
IWZJAFfoTyqdKXe5emT7QsO9nD3jzwy6WAZl++DY9ca5sILy0i+PNpMD7YGrM/CK
zeZvQqYtKdSHQOkqvyNMviciTpypftYhZMvn13H3CQini2YhWfvgfxkWCQ1zidr3
IkJ+SwitmZZYMOI8RCT77NVxdDNqv7F0jTUcLf4mwBm6FWjfUdZCK+ouvqmti+p7
K85x6PNtkav1nEinveS5
=oy0z
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


AW: [bulk]: Re: Is tomcat UserDatabaseRealm buggy?

Posted by "Kehlenbach, Andreas" <An...@PROSTEP.com>.
Hey Chris,

Yes I know that BASIC authentication doesn't use nonces, thus I don't think that this is the root cause. Just forget about the nonce timout.
For full information: I played around with the timeout and used values of 1, 5, 20 minutes.

But as I discovered that also the 401 appears with BASIC authentication I would suggest to test with this.

I reconfigured tomcat, because the configuration differs. That’s what I did to test both cases.

I hope I could create a small test case tomorrow.

Thank you for your answer,
Andreas

> -----Ursprüngliche Nachricht-----
> Von: Christopher Schultz [mailto:chris@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 &quot;%r&quot; %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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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)
________________________________________________________________________

Re: Is tomcat UserDatabaseRealm buggy?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 &quot;%r&quot; %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/1lxVAmXeDshnYP47zSnykhj
wv5z86sX57H480VdYQLIIrTwj9KOa6Wifgd/YkC6fUihLNIa+kOe0Jhoq6+K/IIA
hh9ZHu/qVKUHOsuef5sYD15CWX/VDEkJUyy4G/qvSB1u0dM5vGUkWggZVvn5kwRG
4V0CIg4M4bNAdki3M8ZYKp8fmD5qzYFnfmjJOKwvGiFk4nJjUZG0crVbQC69cyeC
5/7tnzswV6dPwyJdBj0b/yiMx0h58mt0BSKz/VNsukxa2WbP0P9csP7mA9gleFUB
OQdupQ6KE5t8lQBHogHJ7QvjlOJT0Tesqn+NUbNuK8cAmntEg8HQc3b/Erqdly7G
GMIx9dhz381RyRlZbBbvwShVc9PK8H5klDfPlwWAQzXG55+iqSx0LS2yV4X+aAht
dxuE/Jc0gZRcb/s2KeUhNGR//Me1GPHStCl3nGxDMczdriEE0/Af+r6tvtXlwd0W
5SdVO1r3oar5e+aPBQMBqdmw47MyGx+vCdjY4jeuuoBm3XY4V2VJLrpZm993PwTV
HgTqgREvgGzDgYkHy4Mm5Fus6YCw4GWWHjVJeff5DBezXigSBcbKtLWK4HoI1zLA
5k7Gm0liagpPsxovlt+OzgQ/kHqSE7qgTHgAWF8CRthOv4U8y4PJuZjPdvVeX9iE
oTrAPaf7gZymwtORZm1J
=83X2
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org