Hi Malcolm, The right way to contribute a patch is to attach an svn diff to a ticket as a file.
The original ticket has already been included in 4.4, so the proper way to do this is to create a new ticket, and attach the patch to it. Thanks, Karl On Fri, Mar 28, 2014 at 6:58 AM, Malcolm Smith < [email protected]> wrote: > Hi, > > I was very interested in the "HTTPCLIENT-1394: Support for Native windows > Negotiate/NTLM via JNA" patch Ryan McKinley contributed to HTTPCLIENT as it > seemed it would perfect solve the issue many people are encountering moving > Kerberised Java clients to Win7. The issue being that local admin users on > Win7 can't access the TGT via the usual GSSAPI method without running the > app as an Administrator (also a XP Compatibility mode flag fixes it but > neither are very satisfactory). > > I now have the patch up and running in our corporate environment and it > works perfectly, although I had to make a small change to the code. Not > being a participator in the HTTPCLIENT project I'm not sure what the best > way of contributing my patch back is. It is a very small modification. > > Within: > org.apache.http.impl.auth.win.WindowsNegotiateScheme.getToken(CtxtHandle, > SecBufferDesc, String) > The third parameter must be the name of the servicePrincipal. In our case > this is of the form: > > HTTP/[email protected] > > * "myserver.mycomp.com" is the host name of the server we want to connect > to > * "REALM.MYCOMP.COM" is the active directory realm. > > In order to provide this I have introduced the servicePrincipal in the > constructor to: > > public WindowsNegotiateScheme(final String scheme, String > servicePrincipal) { > super(); > > this.scheme = (scheme == null) ? AuthSchemes.SPNEGO : scheme; > this.challenge = null; > this.continueNeeded = true; > this.servicePrincipal = servicePrincipal; > } > > And added it as a field so it can be passed into the getToken method calls. > > > And have also therefore introduced it into the factory so it can be passed > down: > > public class WindowsNegotiateSchemeFactory implements AuthSchemeProvider { > > private String servicePrincipal; > > public WindowsNegotiateSchemeFactory(String servicePrincipal) > { > this.servicePrincipal = servicePrincipal; > } > > public AuthScheme create(final HttpContext context) > { > return new WindowsNegotiateScheme("Negotiate", servicePrincipal); > } > > } > > I can then construct a client in the following way: > > HttpClientBuilder clientBuilder = HttpClientBuilder.create(); > RequestConfig defaultRequestConfig = RequestConfig.custom() > .setSocketTimeout(getTimeout()) > .setConnectTimeout(getTimeout()) > .setConnectionRequestTimeout(getTimeout()) > .build(); > clientBuilder.setDefaultRequestConfig(defaultRequestConfig); > > BasicCredentialsProvider basicCredentialsProvider = new > BasicCredentialsProvider(); > basicCredentialsProvider.setCredentials(AuthScope.ANY, > CurrentWindowsCredentials.get()); > > Lookup<AuthSchemeProvider> authRegistry = new Lookup<AuthSchemeProvider>() > { > @Override > public AuthSchemeProvider lookup(String arg0) > { > String servicePrincipal = "HTTP/" + host + "@ > REALM.MYCOMPANY.COM"; > return new WindowsNegotiateSchemeFactory(servicePrincipal); > } > > }; > clientBuilder.setDefaultCredentialsProvider(basicCredentialsProvider); > clientBuilder.setDefaultAuthSchemeRegistry(authRegistry); > > And we now have Kerberos authentication working perfectly for our users > with local admin rights running Java clients. Also the whole Kerberos > handshake seems must faster, and we can ditch all the usual configuration > that is required for GSSAPI. We will shortly be using this 'experimental' > patch in a production setting and I am confident that it is a robust > solution. > > I am happy to send Ryan the source I have modified if that helps, but I > thought that seeing as he had originally contributed the patch it might be > easier for Ryan to just update his code. > > Kind regards, > > Malcolm. > > Confidentiality - This email is confidential. > Not meant for you? - If you don't think this email is meant for you, > please let us know. Do not copy or forward the information it contains, and > delete this email from your system. > Views expressed - Any personal views or opinions expressed in this email > are the sender's, and do not necessarily reflect the views of Standard Life > group. > Monitoring - We filter and monitor emails to protect our systems and to > keep them running smoothly. > Emailing us - Email isn't a secure form of communication. If you want to > send us confidential information please send it by post. However, if you do > communicate with us by email on any subject, you are giving us permission > to email you back. > Phoning us - Calls may be monitored and/or recorded to protect both you > and us and help with our training. Call charges will vary. > Standard Life group - Standard Life group comprises Standard Life plc and > its subsidiaries. For more information on Standard Life group visit our > website http://www.standardlife.com/. > Standard Life plc (SC286832), Standard Life Assurance Limited (SC286833) > and Standard Life Employee Services Limited (SC271355) are all registered > in Scotland at Standard Life House, 30 Lothian Road, Edinburgh EH1 2DH. > Standard Life Assurance Limited is authorised by the Prudential Regulation > Authority and regulated by the Financial Conduct Authority and the > Prudential Regulation Authority. > For more information on Standard Life Assurance limited visit our website > http://www.standardlife.co.uk > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
