We Keep Coding

Jetty HttpClient proxy authentication configuration (NTLM)

We built a Java client application connecting to an API behind a proxy that demands NTLM authentication. The application uses a Jetty HttpClient.
Unfortunately the authentication fails with a 407
Response headers HttpResponse[HTTP/1.1 407 Proxy Authorization Required]#3577846e
Proxy-Authenticate: Negotiate
Proxy-Authenticate: NTLM
We tried to authenticate using the SPNEGOAuthentication-class
AuthenticationStore authStore = httpClient.getAuthenticationStore();
SPNEGOAuthentication auth = new SPNEGOAuthentication(proxyUrl);
auth.setUserName(user);
auth.setUserPassword(password);
authStore.addAuthentication(auth);
ProxyConfiguration proxyConfig = httpClient.getProxyConfiguration();
HttpProxy proxy = new HttpProxy(proxyUrl.getHost(), proxyUrl.getPort());
proxyConfig.getProxies().add(proxy);
But without success (407). We also tried overwriting the DefaultAuthenticator.
Any hints what we probably did wrong or other suggestions?
Regards and thanks in advance,
Thomas

Unable to connect to email exchange server using Java API.Getting SSLException [duplicate]

This question already has answers here:
Unrecognized SSL message, plaintext connection? Exception
(18 answers)
Closed 6 years ago.
How to resolve the above exception while invoking a .net web service (asmx) hosted on SSL ("https:") protocol from java using axis jars.
Receving the following error message while executing the code:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at com.ibm.jsse2.a.c(a.java:228)
at com.ibm.jsse2.a.a(a.java:63)
at com.ibm.jsse2.jc.a(jc.java:465)
at com.ibm.jsse2.jc.g(jc.java:458)
at com.ibm.jsse2.jc.a(jc.java:67)
at com.ibm.jsse2.jc.startHandshake(jc.java:342)
at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)
at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:191)
at org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:404)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:138)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at examples.Example_client.main(Example_client.java:79)
{http://xml.apache.org/axis/}hostname:D-113020008

It is possible that you are using a proxy to get the ssl content, but your proxy setup is wrong. You should consider using http as proxy scheme, and then https as your scheme for the actual content. This solved my problem.

As the error message says, the probability is that the peer is talking plaintext, not SSL.

I have gotten this error before when my connection was being blocked by complex firewall rules. If you have in place it might be worth looking at the configuration.

Weird error when calling a web service from a Java SE client

I have a java SE client trying to talk to a J2EE web service. We are using Axis 1.4, so when I try to make a call I get the error below:
'- Unable to find required classes (javax.activation.DataHandler and javax.mail.internet.MimeMultipart). Attachment support is disabled.'
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it.
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it.
at com.sun.org.apache.xerces.internal.dom.ParentNode.internalInsertBefore(Unknown Source)
at com.sun.org.apache.xerces.internal.dom.ParentNode.insertBefore(Unknown Source)
at com.sun.org.apache.xerces.internal.dom.NodeImpl.appendChild(Unknown Source)
Here is the call:
JRD_ServiceLocator jserv = new JRD_ServiceLocator();
Object arc[] = jserv.getserviceport( new URL("http://vpnl3-4102.fi.com:7110/jrds/services?WSDL")).getRefDataByQuery("MDS", "FX", "CCY", "CCY='A'");

What a PITA. The web service itself was having problems. I would have thought I would have got a different error, probably not forming the fault right on the server side. Such is life when you are still using Weblogic 9.2.

Axis: faultString: org.xml.sax.SAXParseException: Premature end of file

I have deployed a webservice using servletexec configured with IIS and i can successfully access webservice using anonymous account. But when I enable Windows Integrated Authentication I am getting following error.
- ntlm authentication scheme selected
- Discarding unexpected response: HTTP/1.1 100 Continue
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: org.xml.sax.SAXParseException: Premature end of file.
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}hostname:akvm
org.xml.sax.SAXParseException: Premature end of file.
at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:633)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:719)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1685)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)

It looks like that the Axis client does not like the NTLM authentication challenge. See error message at the top:
Discarding unexpected response: HTTP/1.1 100 Continue
After which there is no XML for Axis to parse, which is why you're getting premature end of file.
In order to use NTLM with Axis (1.4), you'll have to use the CommonsHTTPSender instead of the standard transport:
<transport name="http" pivot="java:org.apache.axis.transport.http.CommonsHTTPSender">
</transport>
in your client-config.wsdd and then set up the NTLM username and password through the Stub object.

The "premature end of file" type errors from the xerces SAX implementation usually indicates that the SAX parser expected data, but got none (not null, but an initialized empty InputSource). From the stack trace, it looks as if the axis SOAP handler expects a SOAP xml message to arrive, but the message is empty. My knowledge of ISS and its infrastructure is close to nil, can you get any log messages from the server?

Java 6 NTLM proxy authentication and HTTPS - has anyone got it to work?

I have a Java application (not an applet) that needs to access a web service. Proxies for the web service have been generated with JAX-WS, and seem to work fine. In one scenario it needs to talk through a web proxy server (actually Squid 3.0), which is set to require NTLM authentication.
Running on Sun's JRE 1.6.0_14, everything works fine for accessing HTTP URLs, without requiring any changes: the built-in NTLM authenticator kicks in and it all works seemlessly. If, however, the web service URL is a HTTPS URL, the web service call fails deep inside Sun's code:
com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.lang.NullPointerException
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:121)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:142)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:211)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:124)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
... our web service call ...
Caused by: java.lang.NullPointerException
at sun.net.www.protocol.http.NTLMAuthentication.setHeaders(NTLMAuthentication.java:175)
at sun.net.www.protocol.http.HttpURLConnection.doTunneling(HttpURLConnection.java:1487)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:164)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:896)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:109)
... 16 more
Looking in Sun's bug database turns up a few exceptions in such classes, but all of them seem to have been fixed. Has anyone come across anything like this? Has anyone got this to work?

After some debugging, this seems to be a flaw in the JRE class libraries, specifically in sun.net.www.protocol.http.HttpURLConnection.
Studying the HTTP requests and responses in the cases of HTTP and HTTPS endpoints showed that, in the successful HTTP case, the requests had a header Proxy-Connection=keep-alive, which was missing on the failing HTTPS case. Reading more generally, there seems to be some confusion on whether one should use "Proxy-Connection" or just "Connection", too ...
Anyway, it is notable that in the HTTP case, the code goes through HttpURLConnection.writeRequests(), which contains the following code snippet
/*
* For HTTP/1.1 the default behavior is to keep connections alive.
* However, we may be talking to a 1.0 server so we should set
* keep-alive just in case, except if we have encountered an error
* or if keep alive is disabled via a system property
*/
// Try keep-alive only on first attempt
if (!failedOnce && http.getHttpKeepAliveSet()) {
if (http.usingProxy) {
requests.setIfNotSet("Proxy-Connection", "keep-alive");
} else {
requests.setIfNotSet("Connection", "keep-alive");
}
There's no such code when creating a tunnel through the proxy for HTTPS, which causes Squid to get upset during the NTLM authentication conversation.
To work around this, in HttpURLConnection.sendCONNECTRequest(), I added
if (http.getHttpKeepAliveSet()) {
if (http.usingProxy) {
requests.setIfNotSet("Proxy-Connection", "keep-alive");
}
}
just before
setPreemptiveProxyAuthentication(requests);
http.writeRequests(requests, null);
I inject my modified HttpURLConnection.class into the JRE using the "-Xbootclasspath/p" flag, and now it works! Not exactly elegant, but there we are.

Are you married to JAX-WS? I use Apache Axis2, which uses the commons httpclient and has NTLM authentication built-in.
Example:
//Configure SOAP HTTP client to authenticate to server using NTLM
HttpTransportProperties.Authenticator auth = new HttpTransportProperties.Authenticator();
//TODO make report server credentials configurable
auth.setUsername("jdoe");
auth.setPassword("strongpass");
auth.setDomain("WINDOWSDOMAIN");
auth.setHost("host.mydomain.com");
auth.setPort(443);
Options o = new Options();
o.setProperty(org.apache.axis2.transport.http.HTTPConstants.AUTHENTICATE,auth);
myWebServiceStub._getServiceClient().setOptions(o);