具有NTLM身份验证的SOAP Web服务的Java客户端
我花了很多天时间试图找到一个可以连接到使用Negotiate / NTLM身份验证的Microsoft Dynamics CRM的正确Java框架。我尝试了有关*和其他资源的所有现有建议，其中包括JAX-WS，Axis2，CXF以及各种HTTP协议处理程序。没有人像预期的那样工作。目前最好的方法是Axis2 / commons-httpclient-3.1，我可以使用NTLM摘要跟踪至少所有三个阶段，但目标IIS仍然拒绝使用401 Unauthorized进行身份验证。 Apache CXF - 具有内置的Java6 NTLM支持和jCIFS，有些人建议作为补救措施，不能正常工作，因为前者在第二个401响应失败（同时它本应发送第三个请求，根据协议），后者尝试从空输入流中读取响应代码并失败。
I spent many days and nights trying to find a proper Java framework that could connect to Microsoft Dynamics CRM which uses Negotiate/NTLM authentication. I tried all existing suggestions on * and other resources with JAX-WS, Axis2, CXF with various HTTP protocol handlers. No one of them worked as expected. The best approach currently is Axis2/commons-httpclient-3.1, where I can trace at least all three phases with NTLM digest, however the target IIS still refuses the authentication with 401 Unauthorized. Apache CXF — both with a built-in Java6 NTLM support and jCIFS, which some people suggested as a remedy, didn't work either as the former fails on the second 401 response (while it should have been send the third request, according to the protocol) and the latter one attempts to read the response code from an empty input stream and fails.
因此，问题是是否有人成功掌握了NTLM-来自Java 6平台的受保护的SOAP Web服务？
So, the question is whether anybody has succeeded to master an NTLM-protected SOAP web service from the Java 6 platform?
我希望其他人可以插入，因为我对这方面的了解现在已经好几年了，也许不是最好的建议 - 特别是，我只使用了commons-httpclient 3而且没有一个新的软件包能够正确地执行NTLM / NTLMv2。
I was hoping somebody else would chime in, as my knowledge of this area is several years old now and perhaps not the best advice - in particular, I've only worked with commons-httpclient 3 and none of the newer packages that promise to do NTLM/NTLMv2 correctly.
您可能已经注意到，commons-httpclient 3的NTLM身份验证代码仅支持NTLM，而不支持较新的NTLMv2协议。我对此问题的解决方案是使用commons-httpclient 3并将NTLM身份验证代码替换为支持NTLMv2的解决方案。幸运的是，NTLMv2规范是由Microsoft发布 。说实话并不是很难实现，但当然现在你需要自己维护一些可能由于多种原因而不可取的东西。
As you've probably noticed, commons-httpclient 3's NTLM authentication code supports only NTLM, not the newer NTLMv2 protocol. My solution to this problem was to use commons-httpclient 3 and replace the NTLM authentication code with an NTLMv2 capable solution. Fortunately, the NTLMv2 specification is published by Microsoft. It's honestly not terrible difficult to implement but of course it's now something you have to maintain yourself which may not be desirable for a number of reasons.