We have customers stating that they're seeing re-authenticate in the Java Plug-In
with MSIE 6, 7, and 8,  
though which versions they're seeing the issue under 
varies by the customer.

The use case is where the user has already answered a basic authentication challenge
with the browser 
(selecting "Remember my password", though the need for this is also
something customers complain bitterly about), 
visit an applet within the web
application that makes HTTP(S) requests requiring authentication of the same site
 
and realm.  In old versions of the Java Plug-In the Java Plug-In forced the user 
to re-enter their credentials.  

In Java 5 and 6, this normally was not necessary (so long as the user selected
"Remember my password"), though 
we'd very occasionally here a complaint that this
didn't work on some isolated machine or another.  
Recently, however, we have had
numereous large customers experiencing this issue. 

We have managed to reproduce the issue in-house, but only with MSIE 7 and HTTPS. 
This is reproducible 
both with our product and a valid commercial certificate
authority and a simple test case with a self-signed 
certificate.

I have attached a simple test case as test.zip (the Java source is in TestApplet.java).

To use this:

   1. Unzip this into an expanded web app doc base.
   2. In the HTML files resulting from the expansion, replace "jessh203l.ptcnet.ptc.com/PDMLinkX20" with your web site hostname/port and web app name.
   3. Expose/host/deploy this doc base via HTTPS (HTTP will not reproduce the issue)
   4. Require basic authentication (using the same realm) on
          * test/appletTest1.html
          * test/appletTest2.html
          * test/testResource.txt
   5. Try appletTest1.html and appletTest2.html with MSIE 7.
          * We see a Java authentication prompt even after having authenticated against the same site and realm at the browser level *and* having checked "Remember my password".? This should not occur and is the customer complaint.
          * The only difference between these 2 is that the appletTest1.html uses <object>/<embed> whereas applet2.html uses <applet>.

Getting a stack trace at this point produces:

	at com.sun.deploy.ui.UIFactory.showPasswordDialog(Unknown Source)
	at com.sun.deploy.security.DeployAuthenticator.openDialog(Unknown Source)
	at com.sun.deploy.security.DeployAuthenticator.getPasswordAuthentication(Unknown Source)
	- locked <0x27fbb0d0> (a com.sun.deploy.security.DeployAuthenticator)
	at java.net.Authenticator.requestPasswordAuthentication(Unknown Source)
	- locked <0x27fbb0d0> (a com.sun.deploy.security.DeployAuthenticator)
	at sun.net.www.protocol.http.HttpURLConnection$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.net.www.protocol.http.HttpURLConnection.privilegedRequestPasswordAuthentication(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getServerAuthentication(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	- locked <0x2887a2e8> (a sun.net.www.protocol.https.DelegateHttpsURLConnection)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)

Just reproduced this on XP. This also appears to be reproducible for MSIE 8 on XP, but not with MSIE 6 on XP

Tried adding the URL in question to the local internet zone in MSIE, but this didn't help at all.