On 12/12/2012, at 4:59 AM, Daz DeBoer wrote: > 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: > 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. > 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. > 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: > Add a switch to choose the NTLM provider to use: jcifs or http-client. For > now, jcifs will be the default. > 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. > 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). > 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. > 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.
We should skip the configure bit and go native with this stuff. If we let Windows generate the tokens for us, then we don't have to worry about never-quite-right emulations in Java, we can make use of other protocols (e.g. Windows Kerberos), the password is never exposed to us (which means we don't need to worry about a trust model to keep 3rd party plugins isolated from the password), and, importantly, the user doesn't need to set any of these garbage system properties and keep them in sync as their password changes. We can do the same for the proxy configuration and then we'd have a nice single-sign-on experience for people using Windows in the enterprise (which is approximately all of our enterprise users). Regardless of how we improve NTLM handling, there are 2 things we'll need before we change stuff: 1. A spec for the improvements. 2. Some integration test coverage (which the spec can describe). I think it's time to get some coverage for this stuff. Why don't you start putting the spec together? -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
