hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Smith <malcolm_sm...@standardlife.com>
Subject HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA
Date Fri, 28 Mar 2014 10:58:05 GMT
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/myserver.mycomp.com@REALM.MYCOMP.COM

* "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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message