DIGEST authentication scheme for Tomcat 3.3

[Attila Szegedi <sz...@freemail.hu>]

Maybe it's a bit late for this, however here it goes; incorporate it if you
like:
I've added support for DIGEST authentication scheme to Tomcat 3.3.

I was able to successfully test it with Opera 5.12 browser WHEN Tomcat
didn't return an Authentication-info header on successful authentication.
Authentication-info header confused the Opera, but that's a bug in Opera I
have reported to their developers. In the code I'm submitting here, Tomcat
outputs Authentication-info headers (since it uses one-time nonces to avoid
replay attacks). This means Opera chokes on it, but to be fair -- I didn't
want to omit Authentication-info just in order to work around a bug in a
browser. My primary goal is to have DIGEST available for use with WebDAV, so
I don't care that much for temporary problems with buggy browsers. (Speaking
of buggy browsers, I've also attempted to test it with IE 5.5 on several
machines, but it didn't work. For the record, this IE 5.5 also didn't work
when recieved a DIGEST authentication challenge from an Apache 3.17 server,
while Opera worked nicely with both my tweaked Tomcat and that counter-test
Apache server.)

Of existing classes, I only had to modify RealmBase and AccessInterceptor in
org.apache.tomcat.modules.aaa. The changes do not affect functionality when
the WEB-INF/web.xml explicitly does not require DIGEST, so I'm willing to
bet my credibility as a software developer it does not break anything
backwards. I also added three new classes: DigestAuthentication,
DigestAuthenticationFactory, and DigestChallenge.

Also, I think that the class BasicAuthHandler in AccessInterceptor.java has
some really messy way of generating output; it uses a StringBuffer stored in
a request note and regenerates the (constant!) output each time. I've done
it as I feel it should be done in my DigestAuthHandler. If someone is
inclined, take a look at it and fix BasicAuthHandler.

Cheers,
  Attila.

Re: DIGEST authentication scheme for Tomcat 3.3

[Attila Szegedi <sz...@freemail.hu>]

Been thinking about how could it be done completely orthogonal to the main
code (that is, as an independent module), but no matter how I look at it, I
can't figure how to acheive the same functionality without touching
AccessInterceptor and RealmBase. OTOH, The Digest* classes can be moved into
a module of their own, there's no problem with that, but AccessInterceptor
and RealmBase still have to know about it. [Or is it just that I don't know
Tomcat architecture closely enough?]

Attila.

----- Original Message -----
From: <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: 2001. szeptember 11. 1:30
Subject: Re: DIGEST authentication scheme for Tomcat 3.3


> Hi Attila,
>
> I'll review your changes and I see no problem with fixing
> AccessInterceptor and RealmBase. I'm not sure about the new modules - I
> think this is a new feature and I'm not very comfortable with features.
>
> If you don't mind, I'll check it in src/proposals first, as a standalone
> module. There we can make sure it works, and eventually release the jar
> separately, for people who need this feature.
>
> As I mentioned many times, it's better for new code to be released as a
> module, either a separate jar file or using the TOMCAT_HOME/modules
> mechanism. Then you can spend all the time you want testing and improving
> your code, and we can release 3.3 ( and 3.3.1, etc ) without extra
> overhead. The more code we have in the main distribution, the hardest it
> is to release the whole thing.
>
>
> Costin
>
>

Re: DIGEST authentication scheme for Tomcat 3.3

[cm...@yahoo.com]

Hi Attila,

I'll review your changes and I see no problem with fixing
AccessInterceptor and RealmBase. I'm not sure about the new modules - I
think this is a new feature and I'm not very comfortable with features.

If you don't mind, I'll check it in src/proposals first, as a standalone
module. There we can make sure it works, and eventually release the jar
separately, for people who need this feature.

As I mentioned many times, it's better for new code to be released as a
module, either a separate jar file or using the TOMCAT_HOME/modules
mechanism. Then you can spend all the time you want testing and improving
your code, and we can release 3.3 ( and 3.3.1, etc ) without extra
overhead. The more code we have in the main distribution, the hardest it
is to release the whole thing.


Costin


On Tue, 11 Sep 2001, Attila Szegedi wrote:

> Maybe it's a bit late for this, however here it goes; incorporate it if you
> like:
> I've added support for DIGEST authentication scheme to Tomcat 3.3.
>
> I was able to successfully test it with Opera 5.12 browser WHEN Tomcat
> didn't return an Authentication-info header on successful authentication.
> Authentication-info header confused the Opera, but that's a bug in Opera I
> have reported to their developers. In the code I'm submitting here, Tomcat
> outputs Authentication-info headers (since it uses one-time nonces to avoid
> replay attacks). This means Opera chokes on it, but to be fair -- I didn't
> want to omit Authentication-info just in order to work around a bug in a
> browser. My primary goal is to have DIGEST available for use with WebDAV, so
> I don't care that much for temporary problems with buggy browsers. (Speaking
> of buggy browsers, I've also attempted to test it with IE 5.5 on several
> machines, but it didn't work. For the record, this IE 5.5 also didn't work
> when recieved a DIGEST authentication challenge from an Apache 3.17 server,
> while Opera worked nicely with both my tweaked Tomcat and that counter-test
> Apache server.)
>
> Of existing classes, I only had to modify RealmBase and AccessInterceptor in
> org.apache.tomcat.modules.aaa. The changes do not affect functionality when
> the WEB-INF/web.xml explicitly does not require DIGEST, so I'm willing to
> bet my credibility as a software developer it does not break anything
> backwards. I also added three new classes: DigestAuthentication,
> DigestAuthenticationFactory, and DigestChallenge.
>
> Also, I think that the class BasicAuthHandler in AccessInterceptor.java has
> some really messy way of generating output; it uses a StringBuffer stored in
> a request note and regenerates the (constant!) output each time. I've done
> it as I feel it should be done in my DigestAuthHandler. If someone is
> inclined, take a look at it and fix BasicAuthHandler.
>
> Cheers,
>   Attila.
>
>