用于IIS集成Windows身份验证（NTLM）的JAX-WS客户端

Question

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.

Answer 1

We are using the JAX-WS that is built in to java 6, and running the client on Windows XP and Windows 2003 Server. The server is IIS 7 on Windows 2003 Server.

I found to my surpise that integrated authentication works out of the box. No configuration supplied. I turned on trace logging at the HTTP layer, and found that NTLM authentication was being used. Not sure if it would work if only Negotiate authentication was being used and NTLM was turned off.

So basically, the answer is: it just works.

To test:

package url.auth;

import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import java.net.URLConnection;
import java.util.List;
import java.util.Map;

import org.apache.commons.io.IOUtils;

public class DownloadUrl {
    public static void main(String[] args) {

        try {
            URL url = new URL("http://myserver/url/that/requires/authentication");
            URLConnection conn = url.openConnection();
            InputStream is = conn.getInputStream();
            Map<String, List<String>> headers = conn.getHeaderFields();
            for(String header : headers.keySet()) {
                System.out.println(header + ": " + headers.get(header));
            }
            System.out.println("");
            System.out.println(IOUtils.toString(is));
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

Answer 2

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

Answer 3

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?