Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sender: jsdever
Message-ID: <3D901CFC.E3750194@sympatico.ca>
Date: Tue, 24 Sep 2002 04:06:20 -0400
From: Jeff Dever <jsdever@sympatico.ca>
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [HttpClient] [prelim-PATCH] NTLM Authentication
References: 
 <0AC2D75550100F4DBDB025D4D05611884481E6@BIGCOW.intraephox.ephox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hey Adrian,

NTLM support is targeted as a HttpClient 2.1 feature on the bug you raised:
http://issues.apache.org/bugzilla/show_bug.cgi?id=10851

There has not been a "feature freeze" for 2.0 yet, so we're still open to adding
this earlier.  There was also the idea for adding "plugable authentication"
modules for just this purpose as well.  You obviously have need for NTLM, so I'm
OK with moving this up, with a few caveats:

1) Using the JCE is preferable to a seperate DES class.  It must only be
required at runtime if the NTLM auth code is actually executed (similar to how
https works currently)
2) Testing for this is going to be difficult.  A nice complete JUnit test suite
is going to be necessisary
3) Need assurance that all code (particularly NTLM.java) is free to be licenced
under the Apache software license.

>From my perspective, if you can meet these requirements, then NTLM is good to go
for 2.0

BTW: Integration into Authenticator looks like the logical, minimal approach.
"Pluggable authentication modules" can just be left as a future enhancement.


> I have now completed a patch to add NTLM authentication to the latest
> version of HttpClient, however there are a couple of issues remaining so it
> should considered "beta-patch" at this point and this is really a request
> for comment rather than a request for commit.  The issues are:
>
> 1. Does not comply with current coding style of HttpClient - particularly in
> the new files.
> 2. Needs improvement to logging
> 3. Requires the Java Cryptography Extensions
>
> The first two just require me to get around to it, the third I'd like some
> comments on.  My preference is to not depend on JCE and to implement DES
> encryption ourselves in a standalone form.  To that end I have implemented
> the DES encryption through a wrapper file so that it is simple to switch
> later if required.  Note that JCE does not work with JRE 1.1 at all and is
> an optional add on for 1.2 and 1.3.
>
> I recieved no reply from an email sent to the author of the DES encryption
> class I have previously mentioned and two of the author's email addresses
> bounced so chance of relicencing it under the Apache License is pretty much
> nil at this point.  I have done some more research and found that the MD4
> encryption can be avoided by using the Windows 98 version of the protocol
> which seems to be more reliable anyway.
>
> Any thoughts, comments or cryptography experts?
>
> The other thing I would like confirmation on is that the integration into
> HttpClient (in Authenticator.java) is the best way to do it.  It certainly
> seems like it is, but I can't be certain of that since I don't know the
> HttpClient code particularly well.
>
> Thanks in advance,


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>