I'm trying to setup up an http client to authenticate with spnego (apache http client 4.5.2)
Here's the code that setups the client
System.setProperty("javax.security.auth.useSubjectCredsOnly", "false");
final CredentialsProvider credsProvider = new SystemDefaultCredentialsProvider();
credsProvider.setCredentials(new AuthScope(null, -1, null), new KerberosCredentials(null));
final HttpClientBuilder builder = HttpClientBuilder.create();
builder.setDefaultCredentialsProvider(credsProvider);
final ApacheHttpClient4Engine engine = new ApacheHttpClient4Engine(builder.build());
final Client client = new ResteasyClientBuilder().httpEngine(engine).build();
On the server, I have a JAX-RS service which is sitting behind a waffle.servlet.NegotiateSecurityFilter to allow for ntlm or spnego authentication.
When I send my HTTP request from my chrome rest client, it works, authentication is successfully completed using negotiate.
When I try and use the apache http client however, it fails with the message in the log:
2018-03-05 16:47:16,048 DEBUG o.a.h.impl.auth.GGSSchemeBase main Authentication already attempted
2018-03-05 16:47:16,048 DEBUG o.a.h.i.auth.HttpAuthenticator main Authentication failed
After some further investigation I've discovered that the waffle filter is encoutingering GSS_S_CONTINUE_NEEDED and responding with an additional challenge which the apache client is simply ignoring and giving up on.
I've tested my apache client setup against another service which uses spnego (provided by a 3rd party) and it works properly, although doesn't employ the continue token.
I'm not sure if my system is setup incorrectly, and that the continue token shouldn't be happeneing or if the apache http client is improperly configured (or doesn't support continue tokens at all)
There's a very old ticket here https://issues.apache.org/jira/browse/HTTPCLIENT-1107 indicating that something was added to handle additional challenges, but from reading the code in org.apache.http.impl.auth.GGSSchemeBase.parseChallenge(CharArrayBuffer, int, int) it looks as though only the first challange is ever accepted.
Related
I am using OkHttp3 in my Android app to make HTTP/1.x requests to my backend servers via a forward proxy, like so:
List<Protocol> protos = new ArrayList<>();
protos.add(Protocol.HTTP_2);
protos.add(Protocol.HTTP_1_1);
InetSocketAddress proxyAddr = new InetSocketAddress("proxy.example.com", 80);
Proxy proxy = new Proxy(Proxy.Type.HTTP, proxyAddr);
OkHttpClient cli = new OkHttpClient.Builder()
.proxy(proxy)
.protocols(protos)
.build();
String url = "http://www.example.com/";
Request req = new Request.Builder().url(url).build();
Response res = cli.newCall(req).execute();
I would like to upgrade to HTTP2. However, it seems to me that OkHttp3 can make HTTP2 requests only if we are not going via a HTTP proxy. So, the above code wouldn't work.
In other words, OkHttp3 supports the first 3 cases below but not the fourth. HTTP/2 below means h2 (HTTP/2 over TLS) not h2c (HTTP/2 over clear text).
a) client <-- HTTP/1.x --> upstream server
b) client <-- HTTP/1.x --> forward proxy <-- HTTP/x --> upstream server
c) client <-- HTTP/2 --> upstream server
d) client <-- HTTP/2 --> forward proxy <-- HTTP/x --> upstream server
Does anyone confirm or deny my understanding? Thanks.
OkHttp will do HTTP/2 over an HTTP proxy. You’ll need HTTPS on the server since OkHttp doesn’t implement plaintext HTTP/2.
Jesse, I tried retrieving https://www.google.com/ with Proxy.Type.HTTP via nghttp2's forward proxy nghttpx, which supports HTTP2 over TLS. Unfortunately, TLS handshaking did not happen and the forward proxy reported the following error.
... tls: handshake libssl error: error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy request
From what I gather, this error means that okhttp3's proxy code is not doing TLS handshaking with the forward proxy.
This makes me think that HTTP2 over TLS via a forward proxy is kind of pointless, because the forward proxy won't be able to add any value to encrypted requests - the forward proxy is just a pass-through pipe. In fact, I think TLS via any forward proxy is pointless. End-to-end HTTP2 over TLS does make sense, but via a forward proxy doesn't.
I am writing a java rest-client to fetch data from the web App. I am trying to use client authentication(login using client certificate) mechanism using spring's RestTemplate to get authenticated on server.
Here are the steps that I did.
Server side:
Configure the web server to allow certificate based login. Set "clientAuth"= "want" in server.xml
Create a clients x509 certificate and add it into servers truststore.
Client Side
Initialize RestTemplate with clients trustStore and keyStore. For this I used org.apache.commons.httpclient.contrib.ssl.AuthSSLProtocolSocketFactory.
AuthSSLProtocolSocketFactory is initialized with client keystore in PKCS12 format, and client truststore (jks format).
Code looks like this:
CommonsClientHttpRequestFactory factory = (CommonsClientHttpRequestFactory) restTemplate.getRequestFactory();
HttpClient client = factory.getHttpClient();
client.getState().setAuthenticationPreemptive(false);
Protocol myHttps = new Protocol(HTTPS, secureProtocolSocketFactory, DEFAULT_HTTPS_PORT);
Protocol.registerProtocol(HTTPS, myHttps);
client.getHostConfiguration().setHost("localhost", DEFAULT_HTTPS_PORT, myHttps);
When I am making rest calls into server I am expecting the request to get authenticated by certificate. But I am getting http 403-forbidden error. It seems that restTemplate is trying to authenticate the request by basicCredentials, where my intent is to authenticate using certificate.
Following is the output logged by http client:
MultiThreadedHttpConnectionManager:390 - HttpConnectionManager.getConnection: config = HostConfiguration[host=https://<server-ip>], timeout = 0
MultiThreadedHttpConnectionManager$ConnectionPool:739 - Allocating new connection, hostConfig=HostConfiguration[host=<server-ip>]
HttpMethodDirector:160 - Preemptively sending default basic credentials
HttpMethodDirector:277 - Authenticating with BASIC <any realm>#<server-ip>:443
HttpMethodParams:355 - Credential charset not configured, using HTTP element charset
HttpConnection:691 - Open connection to 10.112.253.152:443
HttpMethodBase:1235 - Adding Host request header
RestTemplate:559 - GET request for "https://<server-ip>:443/url/" resulted in 403 (Forbidden)
Is there anything else that needs to be configured on RestTemplate to get authenticated using client certificate?
I have developed a Java Applet that works properly in a standard environment (no proxies). On the contrary if the applet is running on a client located behind a proxy, it correctly downloads files and accedes resources with simple http GET methods (java.net) but http POST method using Apache httpclient doesn't work.
I'm using:
HttpClientBuilder clientBuilder = HttpClientBuilder.create();
clientBuilder.useSystemProperties();
CloseableHttpClient httpclient = clientBuilder.build();
to retrieve credentials for proxy authentication (these credentials have been already used by JVM, because I can accede external resources using java.net).
The execution of the POST method results in a 407 error (Proxy authentication required). Why useSystemProperties() can't retrieve the credentials for authentication? How can I retrieve username and passoword for the proxy?
Currently at a loss for authenticating with a Microsoft Project Server 2007 instance running on IIS with Integrated Windows Authentication enabled from a Java 1.6(u19) client running on linux, RHEL 5.5.
Note: The client works on my Windows workstation.
I initially was trying to implement a JAX-WS call and found that I could not retrieve the WSDL due to authentication errors, specifically a 401.2, followed by a 500. So I simplified it to a Java class that:
Creates an Authenticator and sets it as the default with a user name/password in AD that has permissions to the project server site
Create a java.net.URL object
Create a java.net.HttpURLConnection and invoke getInputStream
It is at this point where a failure occurs.
With HttpURLConnection debugging turned on I can see:
the initial authentication failure (401.2) returned from the server with "negotiate" and "NTLM" included in the response.
the client creating an NTLM token and sending it back to the server
the server returning with a 500 status code
On the Windows server in the logs, I can see that there is no user name included in the log file only for my requestion and only a "-" which I believe means "anonymous".
My thought is that Project Server isn't liking the NTLM token that is being passed and choking. Based on the many postings on this, NTLM (v1 & v2) are suppose to be supported within Java 1.6.
Any help would be greatly appreciated...
UPDATE 6/20/12: narrowed the issue down to a local security policy setting for Network security: Minimum session security for NTLM SSP based (including RPC) servers. The setting that causes the Java client to fail is Require NTLMv2 security. The goes against what is claimed for NTLM support with the 1.6 JDK..
Some references:
Java HTTP Authentication
Blog showing Java Authenticator Impl
A while back when i had this problem, i ended up using a scheme created by somebody else.
http://devsac.blogspot.com/2010/10/supoprt-for-ntlmv2-with-apache.html
Worked for me when i had to get image files from and iis server with ntlm.
Snippet using the code above..
AuthPolicy.registerAuthScheme(AuthPolicy.NTLM, org.xyz.JCIFS_NTLMScheme.class);
HttpClient client = new HttpClient();
client.getState().setCredentials(AuthScope.ANY, new NTCredentials(userName, password, "", strDomain));
GetMethod get = new GetMethod(strImageFile);
get.setDoAuthentication(true);
client.executeMethod(get);
We are using Apache Axis client to communicate to a report server. The Apache Client uses Apache Http Client for NTLM authentication. Based on the below post
How can I get jcifs to play nicely with apache axis
it looks like it only supports the primitive NTLM. One of our machines is set to work with the recent NTLM authentication.
I want to know where is this setting where I can reset to use the primitive NTLM authentication supported by Apache Http Client.
HttpClient doesnt support NTLM v2 hence I use JCIFS library to return NTLM v1,2,3 message type as described in this website
http://devsac.blogspot.com/2010/10/supoprt-for-ntlmv2-with-apache.html
I just used the JCIFS_NTLMScheme.java file from the above website to register the auth scheme and it worked !!!!
Sample client:
List authSchema = new ArrayList();
AuthPolicy.registerAuthScheme(AuthPolicy.NTLM, org.tempuri.JCIFS_NTLMScheme.class);
HttpTransportProperties.Authenticator auth = new HttpTransportProperties.Authenticator();
auth.setUsername("");
auth.setPassword("");
auth.setDomain("");
auth.setHost("");
auth.setPort();
List authPrefs = new ArrayList(1);
authPrefs.add(AuthPolicy.NTLM);
auth.setAuthSchemes(authPrefs);
stub._getServiceClient().getOptions().setProperty(org.apache.axis2.transport.http.HTTPConstants.AUTHENTICATE, auth);