[Jakarta-httpclient Wiki] Update of "FrequentlyAskedNTLMQuestions" by RolandWeber

[Apache Wiki <wi...@apache.org>]

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

------------------------------------------------------------------------------
- #pragma section-numbers 2
+ #DEPRECATED
  
- = Frequently Asked Questions About NTLM =
+ This page has been [http://wiki.apache.org/HttpComponents/FrequentlyAskedNTLMQuestions moved]
+ to the new [http://wiki.apache.org/HttpComponents/ HttpComponents Wiki].
  
- ----
- [[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, publicly available, 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 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]
- 
- In the worst case scenario if we are precluded from using jCIFS directly we will host the development of 
- the NTLM authentication scheme outside Jakarta at the !SourceForge or similar site and release it under 
- LGPL as an optional plug-in.
- 
- == 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org