Java 6 Autenticazione proxy NTLM e HTTPS: qualcuno ha potuto farlo funzionare?

Question

Ho un'applicazione Java (non un'applet) che deve accedere a un servizio web. I proxy per il servizio Web sono stati generati con JAX-WS e sembrano funzionare correttamente. In uno scenario è necessario parlare attraverso un server proxy web (in realtà Squid 3.0), che è impostato per richiedere l'autenticazione NTLM.

In esecuzione su Sun's JRE 1.6.0_14, tutto funziona correttamente per accedere agli URL HTTP, senza richiedere alcuna modifica: l'autenticatore NTLM incorporato entra in funzione e tutto funziona senza problemi. Se, tuttavia, l'URL del servizio web è un URL HTTPS, la chiamata di servizio Web non riesce in profondità all'interno del codice di 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 

Guardando nel database dei bug di Sun salta fuori alcune eccezioni a tali classi, ma tutti sembrano sono stati risolti Qualcuno si è imbattuto in qualcosa del genere? Qualcuno l'ha fatto funzionare?

Answer 1

Sei sposato con JAX-WS? Utilizzo Apache Axis2, che utilizza il comune httpclient e ha l'autenticazione NTLM integrata.

Esempio:

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

Dopo un po 'di debug, questo sembra essere un difetto nelle librerie di classi JRE, in particolare in sun.net.www.protocol.http.HttpURLConnection.

Lo studio delle richieste HTTP e delle risposte nei casi di endpoint HTTP e HTTPS ha mostrato che, nel caso HTTP riuscito, le richieste avevano un'intestazione Proxy-Connection=keep-alive, che mancava sul caso HTTPS in errore. Leggendo più in generale, sembra esserci una certa confusione sul fatto che si debba usare "Connessione proxy" o semplicemente "Connessione", anche ...

In ogni caso, è da notare che nel caso HTTP, il codice passa attraverso HttpURLConnection.writeRequests() , che contiene il seguente frammento di codice

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

non esiste codice durante la creazione di un tunnel attraverso il proxy per HTTPS, che fa sì che Squid per arrabbiarsi durante la conversazione di autenticazione NTLM.

Per risolvere questo, in HttpURLConnection.sendCONNECTRequest(), ho aggiunto

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

poco prima

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

inietto il mio modificato HttpURLConnection.class nel JRE utilizzando il flag "-Xbootclasspath/p", e ora Funziona! Non esattamente elegante, ma ci siamo.