Basic and Digest are the two IETF endorsed authentication mechanisms
for HTTP. However, in  customer  (IIS) based environments two additional
schemes are in common use, and are commonly requested for Java.
These are "NTLM" aka Challenge/Response and "Negotiate" which
is a scheme that can use Kerberos or else fallback to the NTLM protocol.

This requirement is frequently requested by plugin and webstart.

[Note. this report is tracking NTLM only. A new report will be opened for
Kerberos]

N/A

After studying the Kerberos based protocol we conclude that we
don't want to implement it. NTLM is widely deployed and we would like
to implement it.

  xxxxx@xxxxx   2002-04-16

This RFE is integrated into Mantis (1.4.2)
  xxxxx@xxxxx  
  xxxxx@xxxxx   2003-04-08

YES!  This is an absolute MUST HAVE!  With IE6 dropping
default java support and the Plug-in making inroads,
corporate users will be SCREWED if they can't download their
applets from a NTLM restricted source. I'm having this very
problem with the Citrix web client because the plugin needs
to download the classes from a NTLM source.  Please support
this authentication before it bites you in the ass later.

I find it difficult to believe this hasn't been handled 
yet.  Please provide this support urgently as customers are 
clamoring for it.

We have an applet that makes an HTTPConnection with its 
originating host. The connection goes through a Microsoft 
ISA Server which requires authentication by "Negotiate" 
authentication scheme. Please provide the support as soon 
as possible

I opened an RFE for this, but it was not accepted on the 
basis that is was too similar to other bugs, so here you go:

There are several problems with network access in the Java
Plug-in.

- Users of sites that require authentication must log in
twice (3-4 times in some cases). Once for the web site and
another time for applets, compounded if a user uses a proxy
server that requires authentication. (see bugs 4166888,
4518282).

- No support for MS Proxy server, a very commonly used
proxy server (see bug 4423881)


Our solution to the first problem is to use a cookie that
is set when the user accesses the web site to authenticate
applet access; however this does not work when the user is
using a proxy server that requires authentication. Our
solution to the second problem (and for users behind
authenticating proxy servers) has always been to require
the users to use to access the applet and to make requests
from the applet using SSL. The result of this was that all
communication was routed through the user?s browser, which
can easily authenticate the user; however, in Java 1.4,
this capability was removed, since now, SSL communication
is handled entirely by Java. This makes 1.4 unusable for
real world applications, and we are forced to keep most of
our users on 1.3.1.

It seems to me that the obvious solution to these problems
is to allow an option to use the browsers? communications
APIs for communication. I realize that this will limit the
flexibility of URLConnection in that context, but I am more
than willing to live with those limitations if it means
that these problems will be solved. I believe that the old
BrowserHttpsURLConnection code could probably be reused to
implement this quite easily.

Preferably, this option should be specifiable as an applet
parameter. Including it solely as an option in the plug-in
control panel would not be the best solution, since it is a
logistical nightmare to walk end users through setting
options there.

Already had this problem at a major banking client.  It's pretty 
embarrassing to have to grovel to their IT people to get an 
application/url on the "free" list they don't filter.  This needs 
to be supported to make the next major step into IT 
infrastructures at major corporations.

If this is not solved you cannot provide any internet 
application written in java in REALWORLD conditions. 
80% of the clients are MS, many use the MS Proxy 2.0. 
Neglegting this reality does not change it.
After two years of waiting the only thing you can do is to 
swit to .NET - if we not already have a running java 
application.
We really need help in this point!!

test

I also ran into this issue but found out that NTLM is only
in Microsoft products (as it's not an offical standard like
basic and digest). I think the solution is to switch to a
standard authentication. Apparently Microsoft's new proxy
server (ISA Server) supports both basic and digest but I
haven't tested to know if it works with Java yet.

This is a big issue!! We need to implement NTLM 
authentication in a Java 2 client soon. I found this 
implementation 
http://www.luigidragone.com/networking/ntlm.html
but it is GNU... does anybody know of any other 
implementations available today.

Yep. After 5 months of work where we migrated from 1.3.1 to 
1.4 we were able to create an applet that doesn't work on 
our clients machine.  The sooner NTLM is in the plug-in the 
better.

We are facing the same problem- Applet connecting thorugh
ISA server using the negotiate. Please Solve it ASAP!!

If you need wider support than mantis, Apache Commons 
HTTPClient has just had NTLM support committed:
http://jakarta.apache.org/commons/httpclient/

What release is 'mantis'?  1.4.x? or 1.5?  In any case, I'm
glad to see this fixed.

-Chris

Here is another library for NTLM with commercial licence if you 
can't wait for Apache/Mantis. Free trial. Developer licenses 
$399. Source available. Haven't tried it yet.
http://www.nogoop.com/

mantis is 1.4.2. A beta version is planned for next month:
Feb 2003. The FCS (official release) will be around May.

Simply cannot believe that Sun has not implemented NTLM, 
what were they thinking ? I was planning to use Java for a 
new applet, but since it won't work in *MOST* cases 
because of this stupid problem, we are forced to use M$ 
development tool... This looks like the end of Java ! 
Sun Java, R.I.P.

The way it's fixed in JDK1.4.2 is not a fix but kind of 
workaround! Users are asked to enter NT account information 
in order to use Plugin-based applets while they really don't 
have to do it while browsing regular pages and applets 
running in the native MS JVM.

JRE has to support NTLM transparently for users. Security 
context should be taken from the current process and 
serialized via SSPI.

This is ridiculous. Please vote for bug 4857110.

We programmed our own wrapper, but it only works from a 
java application where you install a dll into the lib directory of 
the VM as well. If that is done, users can simply select to use 
whatever settings they use in Internet Explorer to connect to 
the web.

"don't want to implement it" sounds ridiculous to me. MS is 
finally starting to follow industry standards with Kerberos, and 
Sun's response sounds lazy and ignores industry standard 
technologies.

I implemented a mixed native-code, java-code 
solution for Windows 98/ME/NT/2k/XP which allows
NTLM authentication using internal Microsoft APIs,
on MS-JVM, and JRE 1.2, 1.3, 1.4.0, 1.4.1.

If you need this, contact alk@pobox.com

The distiction between my method and the HttpClient
approach is that, because I operate at a lower level,
I work with SSL tunnels through proxies.  
It appears that the Sun 1.4.2 fix doesn't address this
case, unfortunately, relying on the synchronous
nature of HTTP.

where can I download this fix , 
i've been looking 4 it for so long .
Thx for making things better !!

nothing works
please help me

i don't know what's going on, but when i try to use some jsp apps behind an isa proxy in my mozilla (linux), some classes are not downloaded.

i think it is a problem with the mozilla java interface, maybe someone can help me.

i have tested wiht mozilla 1.7.3 
debian

j2re 1.4.02_03 _04 _05 and _06
jse 1.5.0  beta

thanks