JDK-7184444 : Java 7 does not properly handle integrated authenticating proxy servers
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2012-07-16
  • Updated: 2013-10-20
  • Resolved: 2012-08-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u10Fixed 8 b50Fixed
Description
FULL PRODUCT VERSION :
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) Client VM (build 23.1-b03, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows 7 Pro SP1, 32 or 64 bit

A DESCRIPTION OF THE PROBLEM :
In Firefox (latest version, 13.0.1) and Internet Explorer 9, I'm finding that when an applet is attempted to be loaded, Java doesn't correctly attempt to use integrated authentication to the proxy server on the first attempt to download the applet.  This causes a prompt to be presented.  If the prompt is cancelled, Java then appears to authenticate properly without the user manually entering credentials.

REGRESSION.  Last worked in version 7

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Open an applet, even Sun's own Java testing applet (http://www.java.com/en/download/testjava.jsp) on a computer configured to use a proxy server with integrated authentication (like Microsoft ISA).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The applet should load without prompting the user to manually authenticate with the proxy server.
ACTUAL -
Java brings up an authentication prompt, even though it is told to use the browser's (Internet Options) settings.  If I select cancel on this prompt, it will generally load the applet as expected.  This happened in a previous release of Java 7, and my hitting cancel caused it to lock my domain account out.  That is particularly bad program behavior.  This happens when we test on multiple computers.  Our end users try to update Java because the program nags them about updating, but it's counter productive when the software doesn't work properly in a typical locked down network environment that uses a proxy server.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Use an older version of Java (ie. version 6, which didn't have this problem).  This is not a good solution because Java is frequently a target for exploits.
Comments
Verified with 7u25-b12
24-05-2013
SQE is OK to take this assuming fix is ready.
27-11-2012
Justification for deferral: Not a regression in this release, which has constrained scope. This was previously fixed in 7u10 and moved out to 7u12. Too risky to address given the date and resources.
31-10-2012
EVALUATION This problem existed in jre 7. It is likely due to after the implementation of the RFE 6893238 (Move NTLM and SPNEGO implementations into separate packages), the DeployAuthenticator.getPasswordAuthentication is being called twice for the ntlm case. One with the "negotiate" scheme which is unknown to deploy code and another one with the "ntlm" scheme".
26-07-2012
WORK AROUND At the java authentication dialog (e.g. the attached negotiate_auth.png), select the "Save this password in your password list" so the the dialog won't popup again after the first time.
26-07-2012
SUGGESTED FIX A possible fix is to return null from DeployAuthenticator.getPasswordAuthentication for the unsupported authentication schemes.
26-07-2012