On 11 December 2012 15:16, Adam Murdoch <[email protected]> wrote: > > 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?
Will do. -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
