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