You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Malcolm Smith <ma...@standardlife.com> on 2014/03/28 11:58:05 UTC
HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA
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
Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA
Posted by Karl Wright <da...@gmail.com>.
Yes, Create Issue is what you want. If you create a ticket that way, there
is a More button, and you can select Attach Files.
Karl
On Fri, Mar 28, 2014 at 9:38 AM, Malcolm Smith <
malcolm_smith@standardlife.com> wrote:
> Karl/Oleg
>
> Thanks for the pointers. I think I will be ok from here on, although will
> need to do this from home as the corporate firewall is getting in the way
> of the SVN connectivity.
>
> When you say raise a ticket - should I use the "Create issue" feature?
> Thing is, I can't see anywhere on that form that would allow me to attach
> the diff?
>
> Malcolm
>
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: 28 March 2014 13:12
> To: HttpComponents Project
> Subject: Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM
> via JNA
>
> On Fri, 2014-03-28 at 08:58 -0400, Karl Wright wrote:
> > Hi Malcolm,
> >
> > To create a patch:
> >
> > -- install an svn client; I use one from SlikSubversion
> > -- check out the svn repository in question:
> >
> > svn co
> > https://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk
> >
> > -- make your change in that tree
> > -- in the httpclient/trunk directory, do the command:
> >
> > svn diff >mypatch.patch
> >
> > To create a ticket, go to https://issues.apache.org/jira, and register.
> > Anybody can register. Create a ticket in the HTTPCLIENT queue,
> > providing a description. Then attach your patch file.
> >
> > Thanks,
> > Karl
> >
>
> Malcolm,
>
> If you are more familiar with GitHub workflow, you can also open a pull
> request against GitHub hosted copy of the HttpClient code repository
>
> https://github.com/apache/httpclient
>
> You'll still need to raise a ticket in JIRA, though.
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional
> commands, e-mail: dev-help@hc.apache.org
>
> 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
>
RE: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via
JNA
Posted by Malcolm Smith <ma...@standardlife.com>.
Karl/Oleg
Thanks for the pointers. I think I will be ok from here on, although will need to do this from home as the corporate firewall is getting in the way of the SVN connectivity.
When you say raise a ticket - should I use the "Create issue" feature? Thing is, I can't see anywhere on that form that would allow me to attach the diff?
Malcolm
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: 28 March 2014 13:12
To: HttpComponents Project
Subject: Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA
On Fri, 2014-03-28 at 08:58 -0400, Karl Wright wrote:
> Hi Malcolm,
>
> To create a patch:
>
> -- install an svn client; I use one from SlikSubversion
> -- check out the svn repository in question:
>
> svn co
> https://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk
>
> -- make your change in that tree
> -- in the httpclient/trunk directory, do the command:
>
> svn diff >mypatch.patch
>
> To create a ticket, go to https://issues.apache.org/jira, and register.
> Anybody can register. Create a ticket in the HTTPCLIENT queue,
> providing a description. Then attach your patch file.
>
> Thanks,
> Karl
>
Malcolm,
If you are more familiar with GitHub workflow, you can also open a pull request against GitHub hosted copy of the HttpClient code repository
https://github.com/apache/httpclient
You'll still need to raise a ticket in JIRA, though.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
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
Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via
JNA
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2014-03-28 at 08:58 -0400, Karl Wright wrote:
> Hi Malcolm,
>
> To create a patch:
>
> -- install an svn client; I use one from SlikSubversion
> -- check out the svn repository in question:
>
> svn co https://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk
>
> -- make your change in that tree
> -- in the httpclient/trunk directory, do the command:
>
> svn diff >mypatch.patch
>
> To create a ticket, go to https://issues.apache.org/jira, and register.
> Anybody can register. Create a ticket in the HTTPCLIENT queue, providing a
> description. Then attach your patch file.
>
> Thanks,
> Karl
>
Malcolm,
If you are more familiar with GitHub workflow, you can also open a pull
request against GitHub hosted copy of the HttpClient code repository
https://github.com/apache/httpclient
You'll still need to raise a ticket in JIRA, though.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA
Posted by Karl Wright <da...@gmail.com>.
Hi Malcolm,
To create a patch:
-- install an svn client; I use one from SlikSubversion
-- check out the svn repository in question:
svn co https://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk
-- make your change in that tree
-- in the httpclient/trunk directory, do the command:
svn diff >mypatch.patch
To create a ticket, go to https://issues.apache.org/jira, and register.
Anybody can register. Create a ticket in the HTTPCLIENT queue, providing a
description. Then attach your patch file.
Thanks,
Karl
On Fri, Mar 28, 2014 at 8:50 AM, Malcolm Smith <
malcolm_smith@standardlife.com> wrote:
> Hi Karl,
>
> I am afraid I am completely unfamiliar with this process. I assume I
> should follow the instructions here for getting hold of the SVN repo:
>
>
> http://wiki.apache.org/HttpComponents/HttpComponentsReleaseProcess?action=show&redirect=HttpComponentsCoreReleaseProcess
>
> How do I go about creating a ticket? Can you point me at some
> documentation?
>
> Thanks,
>
> Malcolm.
>
>
> -----Original Message-----
> From: Karl Wright [mailto:daddywri@gmail.com]
> Sent: 28 March 2014 11:49
> To: HttpComponents Project
> Subject: Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM
> via JNA
>
> 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 <
> malcolm_smith@standardlife.com> 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(CtxtHand
> > le,
> > 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
> >
> >
> 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
>
>
RE: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via
JNA
Posted by Malcolm Smith <ma...@standardlife.com>.
Hi Karl,
I am afraid I am completely unfamiliar with this process. I assume I should follow the instructions here for getting hold of the SVN repo:
http://wiki.apache.org/HttpComponents/HttpComponentsReleaseProcess?action=show&redirect=HttpComponentsCoreReleaseProcess
How do I go about creating a ticket? Can you point me at some documentation?
Thanks,
Malcolm.
-----Original Message-----
From: Karl Wright [mailto:daddywri@gmail.com]
Sent: 28 March 2014 11:49
To: HttpComponents Project
Subject: Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA
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 < malcolm_smith@standardlife.com> 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(CtxtHand
> le,
> 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
>
>
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
Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA
Posted by Karl Wright <da...@gmail.com>.
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 <
malcolm_smith@standardlife.com> 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/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
>
>