hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-httpclient Wiki] Update of "FrequentlyAskedNTLMQuestions" by RolandWeber
Date Wed, 20 Sep 2006 17:50:12 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change

The following page has been changed by RolandWeber:

New page:
#pragma section-numbers 2

= Frequently Asked Questions About NTLM =


== 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'''||
||<:>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.
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.
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: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

View raw message