Java 6 autenticación de proxy NTLM y HTTPS: ¿Alguien ha conseguido que funcione?

Question

Tengo una aplicación Java (no un applet) que necesita acceder a un servicio web. Los proxies para el servicio web se han generado con JAX-WS, y parecen funcionar bien. En un escenario, necesita hablar a través de un servidor proxy web (en realidad, Squid 3.0), que está configurado para requerir la autenticación NTLM.

Al funcionar en Sun's JRE 1.6.0_14, todo funciona bien para acceder a las URL HTTP, sin requerir ningún cambio: el autenticador NTLM incorporado se activa y todo funciona sin problemas. Sin embargo, si la URL del servicio web es una dirección URL HTTPS, la llamada de servicio web falla en el interior de código de Sun:

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 

Buscando en la base de datos de fallos de Sun aparecen pocos excepciones en estas clases, pero todos ellos parecen han sido arreglados ¿Alguien ha encontrado algo como esto? ¿Alguien consiguió que esto funcione?

Answer 1

¿Estás casado con JAX-WS? Uso Apache Axis2, que usa el httpclient común y tiene una autenticación NTLM incorporada.

Ejemplo:

//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); 

Answer 2

Después de algún depuración, esto parece ser un defecto en las bibliotecas de clases JRE, específicamente en sun.net.www.protocol.http.HttpURLConnection.

Al estudiar las solicitudes HTTP y las respuestas en los casos de puntos finales HTTP y HTTPS se demostró que, en el caso HTTP exitoso, las solicitudes tenían un encabezado Proxy-Connection=keep-alive, que faltaba en el caso de HTTPS defectuoso. Leyendo en general, parece haber cierta confusión sobre si se debe usar "Proxy-Connection" o solo "Connection", también ...

De todos modos, es notable que en el caso HTTP, el código pasa por HttpURLConnection.writeRequests() , que contiene el siguiente fragmento de código

/* 
    * 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"); 
    } 

no hay tal código al crear un túnel a través del proxy para HTTPS, lo que provoca calamar a molestar durante la conversación autenticación NTLM.

Para evitar esto, en HttpURLConnection.sendCONNECTRequest(), añadí

if (http.getHttpKeepAliveSet()) { 
    if (http.usingProxy) { 
     requests.setIfNotSet("Proxy-Connection", "keep-alive"); 
    } 
} 

justo antes

setPreemptiveProxyAuthentication(requests); 
http.writeRequests(requests, null); 

me inyecto mi modificado HttpURLConnection.class en el JRE usando la bandera "-Xbootclasspath/p", y ahora ¡funciona! No exactamente elegante, pero ahí estamos.