Klient Java dla usługi sieciowej SOAP z uwierzytelnianiem NTLM

Question

Spędziłem wiele dni i nocy, próbując znaleźć odpowiednią architekturę Java, która mogłaby połączyć się z programem Microsoft Dynamics CRM, który używa uwierzytelniania Negotiate/NTLM. Wypróbowałem wszystkie istniejące sugestie dotyczące Stackoverflow i innych zasobów z JAX-WS, Axis2, CXF z różnymi procedurami protokołu HTTP. Żaden z nich nie działał zgodnie z oczekiwaniami. Obecnie najlepszym podejściem jest Axis2/commons-httpclient-3.1, w którym mogę śledzić co najmniej wszystkie trzy fazy z trawieniem NTLM, jednak docelowy IIS nadal odmawia uwierzytelnienia z 401 nieautoryzowanym. Apache CXF - zarówno z wbudowaną obsługą Java 6 NTLM, jak i jCIFS, które niektórzy sugerowali jako środek zaradczy, nie działał tak, jak poprzedni błąd przy drugiej odpowiedzi 401 (podczas gdy powinno być wysłane trzecie żądanie, zgodnie z protokół), a drugi próbuje odczytać kod odpowiedzi z pustego strumienia wejściowego i kończy się niepowodzeniem.

Pytanie brzmi, czy komuś udało się opanować usługę sieciową SOAP chronioną NTLM z platformy Java 6?

Answer 1

Miałem nadzieję, że ktoś inny zadzwoni, ponieważ moja wiedza na ten temat ma już kilka lat i być może nie najlepsza rada - w szczególności pracowałem tylko z commons-httpclient 3 i żadną z nowszych paczek obiecuję poprawnie wykonać NTLM/NTLMv2.

Jak zapewne zauważyłeś, kod uwierzytelniający NTLM httpclient 3 obsługuje tylko NTLM, a nie nowszy protokół NTLMv2. Moim rozwiązaniem tego problemu było użycie commons-httpclient 3 i zastąpienie kodu uwierzytelniającego NTLM rozwiązaniem obsługującym NTLMv2. Na szczęście specyfikacja NTLMv2 to published by Microsoft. Naprawdę nie jest to trudne, ale oczywiście jest to coś, co trzeba zachować, co może nie być pożądane z wielu powodów.

Answer 2

Zapomniałem, więc powiedz, że sam znalazłem rozwiązanie. Kluczem jest zastąpienie standardowego stosu protokołu Java numerem Jespa + jCIFS i wykonanie niewielkiej poprawki do pracy z JAX-WS.