G'day
I've been investigation some NTLM proxy authentication issues (
http://forums.gradle.org/gradle/topics/proxy_error-1r4f6), and I think
there are things that need addressing:

   1. We always attempt NTLM authentication, even if the user hasn't
   supplied a domain explicitly via the 'http.auth.ntlm.domain' system
   property or implicitly via a username like 'DOMAIN/USERNAME'. In this case
   we use an empty string for domain name: I'm not sure if this _ever_ will
   successfully authenticate. The issue here is that if the server supports
   both NTLM and BASIC auth and the user supplies BASIC auth credentials, then
   authentication will fail due to NTLM authentication failing.
   2. The built-in NTLM support that comes with HttpClient has been
   steadily improving (and will further in v4.3). We provide no way to use
   this built-in support instead of the JCIFS implementation.
   3. We always attempt NEGOTIATE authentication, even if the system
   doesn't support it. This results in the following warning being emitted:
   NEGOTIATE authentication error: Invalid name provided (Mechanism level:
   Could not load configuration file C:\WINDOWS\krb5.ini (The system cannot
   find the files pecified))

So I propose the following changes:

   1. Add a switch to choose the NTLM provider to use: jcifs or
   http-client. For now, jcifs will be the default.
   2. Deprecate any implicit way of supplying the NTLM 'domain' string:
   instead we require the 'http.auth.ntlm.domain' property to make NTLM
   authentication work. We would also need to deprecate the case where the
   default empty domain is used successfully for NTLM authentication. Once we
   remove the deprecated behaviour, we would only set NTLMCredentials (and
   enable NTLM auth) when the NTLM domain is specified explicitly.
   3. Add a DSL-based way to specify the NTLM domain (and workstation), in
   addition to the system property. (This would not be suitable for proxy
   authentication, but would work for target authentication).
   4. First check if the NEGOTIATE scheme is available locally before
   adding to the schemes that will be attempted: not sure exactly how to do
   this, but it should be possible.
   5. Detect when proxy authentication fails, and provide useful feedback
   about the system properties that can be used to configure it (or a User
   Guide link).

Of these, the first seems very easy to implement, since applying the jcifs
provider is a one-liner, which we would then call selectively based on the
switch.

Proxy authentication can cause a very negative out-of-the-box experience
when it doesn't work. We could certainly do more to make this work better
and make it easier to configure.

--
Darrell (Daz) DeBoer
Principal Engineer, Gradleware
http://www.gradleware.com

Reply via email to