FULL PRODUCT VERSION :
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b02)
Java HotSpot(TM) Client VM (build 1.5.0_16-b02, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
We have auth.conf file in a jar file. This works with update 15. When we initiate login it is failing with
Caused by: java.lang.SecurityException: jar:auth-client.conf (No such file or directory)
 at com.sun.security.auth.login.ConfigFile.<init>(Unknown Source)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
 at java.lang.reflect.Constructor.newInstance(Unknown Source)
 at java.lang.Class.newInstance0(Unknown Source)
 at java.lang.Class.newInstance(Unknown Source)
 at javax.security.auth.login.Configuration$3.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.login.Configuration.getConfiguration(Unknown Source)
 at javax.security.auth.login.LoginContext$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.login.LoginContext.init(Unknown Source)
 at javax.security.auth.login.LoginContext.<init>(Unknown Source)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Put auth.conf in a jar file and try to login from a client.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
 System.setProperty("java.security.auth.login.config", getClass().getResource("/auth-client.conf").toExternalForm())
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None so far.

Release Regression From : 5.0u15
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
Posted Date : 2008-08-06 08:38:52.0

N/A

see comments
Posted Date : 2009-08-31 23:56:50.0

More Information: This appears to be a problem with the external form "jar: auth-client.conf". In jdk 1.6 update 7 the same code produces quite a different external form: "jar:http://localhost:8080/jaws/jawsclient.jar!/auth-client.conf". Interestingly, when this latter external form is used in 1.5.0_16 (i.e. hard-coded instead of calling toExternalForm()) then things work. It seems 1.5.0_16 should be generating the http external form but isn't...

We have experienced the same problem with client applications which use JAAS configuration files. But in our scenario this is only a WebStart specific problem. It works well for all applications that are not deployed to client machines via WebStart. In current JRE versions the JNLPClassloader does not return a valid URL to the physical location of the configuration file on the file system, in contrast to the standard Java system classloader. Hence, JAAS is not able to load its configuration file from the URL passed via the system property "java.security.auth.login.config".

It seems that this "enhancement" of the JNLPClassloader has broken the JAAS support in Java WebStart. It there is no workaround available, this bug is a real showstopper, since it prevents client applications from using the latest JRE versions.

We are facing the same problem when deploying our application with JWS found in 5.0u16.

The problem might be introduced by the fix for "Security Problem 238905" ( CR 6704074: A vulnerability in Java Web Start may allow an untrusted Java Web Start application to determine the location of the Java Web Start cache )

Java 6 seems to handle this very different: the returned URL dosn't contain the local URL in the cache but the original Http URL of the JAR file, so no information about the local cache location is available to the application).

Unfortunaltely 5.0u16 not only omits the local cache location from the URL for untrusted but also for trusted applications which request "all-permissions" which doesn't seem to make too much sense to me.

Any ETA for a fix? Would that be in 1.5.0_17? Thanks!

Isn't this a duplicate of bug #6746185? That one has been fixed already and is scheduled to be released into 1.5.0_17.