views:

1043

answers:

2

Recently, I am working on a project that requires to build a web service client in Java running on JAX-WS engine to talk to a .NET web service secured by Integrated Windows authentication (also known as NTLM protocol)

I searched on the Internet. It seems a well-known issue, but no one has good solution yet.

Anyone has done this before?

Any suggestion will be appreciated.

A: 

Java HTTP Client Options This section talks about the known implementations of NTLM support with a Java HTTP client so that you can select the implementation that best serves your needs.

The available implementations are:

Sun JRE 1.4.2 or higher (free) - Full support of NTLM protocol (LM/NTLM/NTLM V2) on the Windows platform only. Supports all NTLM configuration levels (I would imagine, I have not tried). Sun JRE 6 or 5 (only 1.5_08 or higher) (free) - Full support of NTLM protocol (LM/NTLM/NTLM V2) on all platforms. Supports all NTLM configuration levels (I would imagine, I have not tried). However, on a Windows machine, it assumes you wish to authenticate using the currently logged on user. You can work around this only after the authentication fails. Jakarta (Apache) HTTP Client (free, Apache license) - Support for LM/NTLM (not NTLM V2) protocol on all Java platforms. Requires JRE 1.2 or higher. Not plug-compatible with the Java UrlConnection classes. No support for OEM encoding (as required by certain proxy servers). NTLM support was added quite a while ago and they don't appear to be interested in extending it. Supports NTLM configuration levels 0-3 only. Innovation HTTP Client w/Luigi Dragone NTLM support (free, LGPL) - Status of this is not clear; I had difficulty getting it to work reliably, and the software has not been released since 2002. It is not plug-compatible with the Java URLConnection classes. Probably supports only NTLM configuration levels 0-3 only. JCIFS (free, LGPL)- Plug-compatible support for LM/NTLM (not NTLM V2) on all Java platforms. Not clear if OEM encoding is implemented. Supports NTLM configurations levels 0-3 only. Oakland Software Java HTTP Client (not free) - Full plug-compatible support of LM/NTLM/NTLMv2 on all Java platforms JRE release 1.2 or higher. Supports both Unicode and OEM encoding. Supports all NTLM configuration levels. If your Java implementation is 1.4.2 or greater and you are running Java on Windows, use the built in JRE support and you are done. Use the java.net.Authenticator class optionally in conjunction with setting some networking properties

If you can change the Windows machine to an NTLM configuration level less that 4 (to not require NTLM V2), and make sure the Network security: Minimum session security for NTLM SSP based (including secure RPC) servers is not set to require NTLM V2, then use either the Jakarta HTTP Client (if you don't care about plug compatibility) or the JCIFS HTTP client if you do. Also, if you are accessing your HTTP server through a proxy that supports only OEM encoding for NTLM, then you cannot use the Jakarta HTTP client (is this also true of JCIFS?).

Note however, there is a potential compatibility related downside to the JCIFS HTTP client

Janie
Your assertions about JCIFS are quite far off. JCIFS has the code to all permutations of NTLM as a client but the JCIFS HTTP client is just a wrapper around the Sun client which means it is basically totally broken. But JCIFS' NTLM code could be used with an HTTP client library to make a very effective solution. But the best solution is the Jespa library which includes an NTLMv2 HTTP client that is documented, supported and easy to understand and use.
A: 

from http://jcifs.samba.org/ , it show jcifs-1.3.1 released / NTLM HTTP Filter Fixed . does that mean can use http filter with ntlmV2 without problem?

cometta