JGridstart/Bouncycastle and Java Web start workaround

Please read Bouncycastle and Java Web Start for the recommended way to use them together. This page describes a workaround that doesn't need signing the BouncyCastle JAR twice.

Workaround: one warning dialog only (Sun JRE)

Note that this workaround appears to work only for Sun Java, not for OpenJDK. The following section describes how to get the best of both worlds.

The security warning for the BouncyCastle extension (the second warning) can be avoided if one uses a policy file in the application. This policy file explicitely grants access to certain operations, and these operations can be BouncyCastle's as well. So we get the following files

app.jnlp (note the new property tag):

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" href="app.jnlp" codebase="http://somewhere/">
  <information>
    <title>App</title>
    <vendor>Nikhef</vendor>
    <homepage href="http://somewhere/"/>
  </information>
  <security>
    <all-permissions/>
  </security>
  <resources>
   <j2se href="http://java.sun.com/products/autodl/j2se" version="1.3+"/>
   <jar href="app.jar"/>
   <extension name="BouncyCastle cryptography library" href="bcprov.jnlp"/>
   <property name="java.security.policy" value="http://somewhere/bcprov.policy"/>
  </resources>
  <application-desc main-class="app.Main"/>
 </jnlp>

bcprov.jnlp, now without any permissions (note the removed security section):

 <?xml version="1.0" encoding="UTF-8"?>
 <jnlp spec="1.0+" codebase="http://somewhere/" href="bcprov.jnlp">
  <information>
   <title>bcprov-jdk14</title>
   <vendor>Sun Microsystems, Inc.</vendor>
   <offline-allowed/>
  </information>
  <resources>
   <jar href="bcprov-jdk14-142.jar"/>
  </resources>
  <component-desc/>
 </jnlp>

and a new bcprov.policy, which grants BouncyCastle its access:

 grant {
  // allow BouncyCastle to register itself
  permission java.security.SecurityPermission "Security.insertProvider.BC";
  permission java.security.SecurityPermission "putProviderProperty.BC";
  // allow access to BouncyCastle properties
  permission java.util.PropertyPermission "org.bouncycastle.*","read";
 };

Note that bcprov.policy is referenced using the full url, it is not located in the application's jar.

Because the property java.security.policy is not a safe property, java web start will see the application as unsigned, even if the JAR is signed. So one needs to sign the JNLP file as well to avoid this warning.

This method avoids a second permission dialog for the BouncyCastle JAR using the Sun Java runtime environment. OpenJDK's runtime environment still requires all-permissions in bcprov.jnlp's security section, which triggers the second permission dialog. This is tackled in the next section.

Full workaround: Sun & OpenJDK

While it is thus possible to avoid the BouncyCastle permission dialog for the Sun JRE, the OpenJDK JRE still requires all-permissions. So the Sun Java Web Start application needs to be served a different bcprov.jnlp than the OpenJDK Java Web Start application. Luckily, it is possible to distinguish between the two (altough more an accident that the developers' purpose) by looking at the HTTP request headers: when UA-Java-Version exists as a header, it is the Sun JRE; if not, it is the OpenJDK JRE.

With the widely used Apache web server it is possible to use its mod_rewrite to do this easily. One needs the app.jnlp as in the previous section (with the security policy), and the two species of bcprov.jnlp. Let's call the first version (with all-permissions in the security section) bcprov.policy, and the second version (without a security section) bcprov-sun.jnlp (don't forget to update its href accordingly). Now add the following to your .htaccess file:

 RewriteEngine On
 # you may need a RewriteBase directive here
 RewriteCond %{HTTP:UA-Java-Version} !^$
 RewriteRule bcprov.jnlp bcprov-sun.jnlp

Now the OpenJDK JRE is served the file bcprov.jnlp just like without a .htaccess, and the Sun JRE is served bcprov-sun.jnlp when it requests bcprov.jnlp. So all are happy now!

---

I have tested this only with <all-permissions/> in the security section. If you have experiences with <j2ee-permissions/> please notify me and I'll add it here.