Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change notification.
The following page has been changed by RolandWeber: http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedNTLMQuestions New page: #pragma section-numbers 2 = Frequently Asked Questions About NTLM = ---- [[TableOfContents]] ---- == What is NTLM? == NTLM is a proprietary protocol conceived by Microsoft. It can be used, among other things, to authenticate against Microsoft HTTP servers and proxies. There is no official, complete documentation of the protocol. Most of the information that can be found on the internet had to be gathered through reverse engineering. There are two versions of the NTLM protocol, commonly referred to as NTLMv1 (version 1) and NTLMv2 (version 2). There's also a stripped-down version of NTLMv2 called LMv2 mentioned in the [http://jcifs.samba.org/src/docs/faq.html#ntlmv2 jCIFS FAQ]. == Does HttpClient support NTLM authentication? == [http://jakarta.apache.org/commons/httpclient/ HttpClient] supports NTLMv1. It does not support NTLMv2 nor LMv2. We happen to have an NTLMv1 implementation in our code base, and we'll continue to support it. But we don't have the resources or the inclination to implement (NT)LMv2. !HttpClient is about HTTP, not NTLM. Besides, developing an NTLM implementation is a legal minefield we don't want to get into. We even had to reject a LMv2 contribution because of licensing issues. == Will HttpComponents support NTLM authentication? == We hope to make use of [http://jcifs.samba.org/ jCIFS] to support both NTLMv1 and LMv2 in [http://jakarta.apache.org/httpcomponents/ HttpComponents]. Even they don't seem to have enough information to implement [http://jcifs.samba.org/src/docs/faq.html#ntlmv2 NTLMv2]. == Why don't you use jCIFS to support NTLM in HttpClient? == [http://jcifs.samba.org/ jCIFS] is licensed under the [http://www.gnu.org/licenses/lgpl.html Lesser General Public License] (LGPL). This license is not compatible with the [http://www.apache.org/licenses/ Apache Public Licenses] under which all Apache Software is released. A lawyer of the Apache Software Foundation is currently investigating under which conditions Apache software is allowed to make use of LGPL software. Once we know the conditions, we'll consider dropping our own NTLM code in favor of using jCIFS for both !HttpClient and !HttpComponents. See also: * [http://wiki.apache.org/jakarta/Using_LGPL'd_code Jakarta Wiki: Using LGPL'd Code] * [http://jakarta.apache.org/site/pmc/board-report-december2005.html Jakarta Board Report Dec 2005] * [http://jakarta.apache.org/site/pmc/board-report-december2004.html Jakarta Board Report Dec 2004] == Could I use jCIFS to support NTLM in HttpClient? == Yes, you could. The legal nightmare starts only when you want to distribute that code. Or so I think. == Why does HttpClient require me to enter the password? IE doesn't! == !HttpClient is platform independent, including the NTLMv1 support. We have code that takes as input user name, password, and domain, and then authenticates the user. The IE feature to automatically use the credentials of the logged in user is Windows only. It makes use of native Windows APIs. == Why does HttpClient require me to enter the password? SUN JDK doesn't! == SUN has licensed the NTLM protocol from Microsoft. They have signed a contract, and probably a Non-Disclosure Agreement, to obtain the permission and necessary documentation for using NTLM. Even so, they have obtained the license only for the Windows platform. They make use of native code accessing native Windows APIs somewhere in their NTLM implementation. We're in no position to match that effort. Neither will we use internal SUN APIs that are available only on the Windows platform. If they are accessible in the first place. == Could I obtain the password from Windows and give it to HttpClient? == No, almost surely not. The SUN JDK code that uses the current user's credentials for NTLM authentication does not obtain the password. Rather, it uses a native API to obtain a hash value that must be computed based on the password during NTLM authentication. You could analyze the SUN JDK code to see whether you can call that step from outside. Or you implement some native code on your own to do the same thing. Then you'd have to modify the NTLM implementation in !HttpClient to use that native code instead of computing the hash value directly. Good Luck. == Would I have to enter the password when using jCIFS? == Yes, almost surely so. The [http://jcifs.samba.org/ jCIFS] website says it's pure Java and cross-platform, so they don't use native or Windows specific code. == Couldn't you use the functionality of HttpURLConnection in HttpClient? == No. There are different layers of connections, and HttpURLConnection is on the wrong one. Have a look at the following figure: ||<:>'''Protocol'''||<:>'''SUN API'''||<:>'''!HttpClient API'''|| ||<:>HTTP||[http://java.sun.com/j2se/1.4.2/docs/api/java/net/HttpURLConnection.html HttpURLConnection]||!HttpClient|| ||<:>TLS/SSL||[http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSocket.html SSLSocket]||!SecureProtocolSocketFactory|| ||<:>TCP/IP||[http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html Socket]||!ProtocolSocketFactory|| At the bottom, there is the TCP/IP layer, accessible through plain Socket connections. !HttpClient can use those. If you need to connect through a SOCKS proxy, that happens on this layer. [[BR]] The middle layer adds encryption. TLS stands for Transport Layer Security, the successor to the Secure Sockets Layer protocol. Encryption is available through SSLSocket connections. !HttpClient can use those. If you need to connect via SSL with client authentication, that happens on this layer. [[BR]] At the top layer is the HTTP protocol. This is where NTLM authentication takes place. SUN has an HTTP implementation, and an NTLM implementation that is hardcoded against it. We have an alternative HTTP implementation, and an NTLM implementation that is based on the !HttpClient API. We can't use the SUN NTLM implementation because it is hardcoded against a different HTTP API, and because it's not public anyway. And we can't run !HttpClient over HttpURLConnection because they're both on the same layer. It's like trying to use two modems over the same phone line. It cannot work. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
