HOWTO: Deploying Java in Internet Explorer 4.0 and Netscape 4.0

• Microsoft Win32 Virtual Machine for Java
• SDK for Java, versions 2.0, 2.01

SUMMARY

The Need to Sign Java Code

Java code can typically be grouped into two categories: applications and applets. Java applications are installed on the user's machine and have complete access to all system resources. Java applets, however, were restricted to the "sandbox." This meant that they were restricted from doing certain tasks, like reading or writing to the hard drive. These restrictions were necessary to provide a secure environment for applets to run in but they also severely restricted their functionality.

MORE INFORMATION

Early Solutions

The first attempt to solve this problem was in Microsoft Internet Explorer 3.0. Using a technology called Authenticode (see below for a description), developers could sign files that contained their Java applets. When the CAB file was downloaded from a Web page, a certificate dialog box was presented to the user. If the user trusted the publisher of the code, the Java code was treated as fully trusted and would have complete access to system resources. If the user did not trust the publisher of the code, the applets were denied access. Sun, in its JDK 1.1 release also had a similar, binary model. Netscape Navigator 3.0 did not have a comparable security model.

Current Models

In the 4.0x releases of Internet Explorer and Netscape Communicator, the binary model was extended to a more fine-grained access of system resources. (At the time of release of Internet Explorer 4.0, Sun had not yet released their JDK 1.2 security model, which also promised fine-grained access functionality). Internet Explorer 4.0x additionally includes a feature called the Package Manager that allows developers to install applets locally and other features such as versioning, namespace management, and so forth. For end users this resulted in benefits such as reduced download time since the applet did not have to be downloaded every time a Web page was hit.

Differences Between the Microsoft and Netscape Models

There are five significant differences between the Java security models in Internet Explorer 4.0x and Netscape Communicator 4.0. These differences and workarounds, if applicable, are described below.

Packaging:

In order to step out of the Java "sandbox," applets need to be packaged in CAB files for use with Internet Explorer 4.0x and into JAR files for use with Netscape Communicator. In order to create CAB files, you need to use the Cabarc or Dubuild utilities. Details about the Cabarc utility is available in the Microsoft SDK for Java 2.0x (http://www.microsoft.com/java/sdk/) in the tools section. To create a JAR file for Netscape Communicator, you need to use the JAR packager utility from a Web page or the Zigbert utility that can be run from the command line.

Installing Java Applets and Applications:

Java applets and applications may be installed using the Package Manager that is available as a new feature in Internet Explorer 4.0x. Some of the advantages of using the Package Manager are versioning control, application namespace management, improved security, ability to uninstall, and ease of use. In order to use the Package Manager in Internet Explorer 4.0x, you need to use the dubuild utility to create a Distribution Unit. There is no equivalent package management facility in Netscape Communicator 4.0. Details about the Package Management feature is available in the SDK for Java 2.0x (http://www.microsoft.com/java/sdk/).

Signing Code:

Signing Java code uses a technology called Authenticode in Internet Explorer and Object Signing in Communicator. Authenticode technology was introduced as a feature in Internet Explorer 3.0 and allowed signed CABS to step out of the sandbox. In Internet Explorer 4.0x this feature was extended to allow Java code fine-grained access to system resources. Both CABs and JARs are signed using industry standard X. 509 v3 certificates and PKCS #7 signatures. Currently, Verisign is the only Certificate Authority (CA) that issues Microsoft Authenticode and Netscape Object Signing certificates. However, these certificates are not interchangeable. In addition, Communicator does not recognize CAB files or the signature that is embedded in a CAB file. Internet Explorer 4.0x can download jar files but does not recognize the signature in a JAR file. In order to sign code, developers should use the Signcode utility. The Signcode utility allows developers to sign their code with the specific permissions that are being requested. Details are available at http://www.microsoft.com/java/security/secfaq.htm. The signcode utility is available in the SDK for Java 2.0x (http://www.microsoft.com/java/sdk).

Security Model:

The security model in version 4.0x of Internet Explorer and Communicator allows Java applets to selectively step out of the sandbox. Both use a trust model that explicitly requires user permission before the code is allowed access to system resources. However, there are a few differences between the two models. The Microsoft model is a static model that requires the user to trust the code up front. In contrast, the Netscape model is a dynamic model where the code requests user input during its execution. This results in the user being presented with multiple dialog boxes at unpredictable times. The Microsoft model allows parameterization of the permissions giving developers and users fine-grained access to resources. For example, in the Microsoft model, a publisher can request access to a particular file on the users hard drive; this level of detail is not available in the Netscape model. The Microsoft model is often referred to in documentation as "Trust Based Security Model for Java" while the Netscape model is often referred to as "Capabilities Based Model." Details about the Microsoft model and comparison with other models are available at http://www.microsoft.com/java/security/.

As described above, the Netscape model requires developers to write to a capabilities API. This results in developers having to maintain two separate code bases for deploying code for both browsers. One way to avoid having to maintain separate code bases is to make the security class files visible on the class path while compiling your Java code. You can then catch the ClassNotFound exceptions and take appropriate action.

The Microsoft model does not require developers to write to an API since the permissions are encoded in the signature. However, an API is provided for classes that need to assert or deny permissions. For example, if you are developing a library, you may want to explicitly assert your permission to access system resources. Details on the assert permission interface are provided in the documentation for the SDK for Java 2.0x (http://www.microsoft.com/java/sdk) and the following Knowledge Base article:

   ARTICLE-ID: Q175622
   TITLE     : PRB: SecurityExceptionEx Exception Running a Java Applet

To download a CAB file with Java code, you need to use the applet tag with the Cabbase parameter. This works with Internet Explorer version 3.0 and 4.0x.

   <APPLET
      code=MyClass.class
      width=100
      height=100>
   <PARAM NAME=cabbase VALUE=MyApplet.cab>
   <PARAM NAME=... VALUE=...>
   </APPLET>

   <APPLET
      code=com.mycorp.AppletMain
      width=100
      height=100>
   <PARAM NAME=useslibrary VALUE="MyApplet">
   <PARAM NAME=useslibrarycodebase VALUE="MyApplet.cab">
   <PARAM NAME=useslibraryversion VALUE="1,1,2,3">
   <PARAM NAME=... VALUE=...>
   </APPLET>

   <APPLET
      code="MyApplet"
      width=200
      height=200>
      archive="test.jar">
   <PARAM NAME="ApplicationClass" VALUE="mycompany.MyApplet">
   <PARAM NAME=... VALUE=...>
   </APPLET>

Internet Explorer 4.x looks for the Useslibrary parameter first and will then look for the Cabbase parameter. Internet Explorer 3.x will not see the Useslibrary parameter, but will see the Cabbase parameter. The important feature to note regarding Useslibrary is that it will install the package on the user's machine permanently until they are removed by the user, whereas the Cabbase parameterwill simply download and use the CAB every time the user hits the page. Also note, the Internet Explorer 3.x method using Cabbase will also work on Internet Explorer 4.x and is sometimes the best solution. Communicator does not recognize the Cabbase or Useslibrary parameter and will ignore it. The author of the page will need to decide on the most appropriate combination of tags/parameters.

NOTE: If you use the Useslibrary and Cabbase parameters together, both CAB referenced by these parameters will be searched before individual class files that may exist on the Web server. This may cause a performance loss and should be noted if some Java classes needed by the applet exist only outside of the cabs on the Web server:

   <APPLET
      code="MyApplet"
      width=200
      height=200>
      archive="test.jar">
   <PARAM name="ApplicationClass" value="mycompany.MyApplet">
   <PARAM NAME=cabbase VALUE=MyApplet.cab>
   <PARAM NAME=useslibrary VALUE="MyApplet">
   <PARAM NAME=useslibrarycodebase VALUE="MyApplet.cab">
   <PARAM NAME=useslibraryversion VALUE="1,1,2,3">
   <PARAM NAME=... VALUE=...>
   </APPLET>

   ARTICLE-ID: Q177159
   TITLE     : INFO: Support for Multiple CABs or JARs in the Same
                     APPLET Tag

   <SCRIPT>
      ua=navigator.userAgent;
      v=navigator.appVersion.substring(0,1);
      if (ua.lastIndexOf("MSIE")!=-1)
   {
      if (v == '4')
      {
       'do IE4.x stuff here
      }
      else if (v == '3')
      {
       'do IE3.x stuff here
      }
      else
      {
       'do other browser stuff here
      }
  }
  </SCRIPT>

REFERENCES

For the latest Knowledge Base articles and other support information on Visual J++ and the SDK for Java, see the following page on the Microsoft Technical Support site:

   http://support.microsoft.com/support/visualj/
   http://support.microsoft.com/support/java/

Keywords          : CmdLnUtils JCab JVM VJMisc
Technology        : internet kbInetDev
Version           : WINDOWS:2.0,2.01
Platform          : WINDOWS
Issue type        : kbhowto