Article ID: 179652
Article Last Modified on 8/10/2006
APPLIES TO
- Microsoft Java Virtual Machine
- Microsoft Software Development Kit for Java 2.02
- Microsoft Software Development Kit for Java 3.2
- Microsoft Software Development Kit for Java 2.01
- Microsoft Software Development Kit for Java 2.02
- Microsoft Software Development Kit for Java 3.0
- Microsoft Software Development Kit for Java 3.1
- Microsoft Internet Explorer 4.01 Service Pack 1
This article was previously published under Q179652
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 documentation in the tools section. (For more information, visit the following Microsoft Web site:http://www.microsoft.com/mscorp/java/) 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 documentation (For more information, visit the following Microsoft Web site:http://www.microsoft.com/mscorp/java/)
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/mscorp/java/ The signcode utility is available in the SDK for Java 2.0 and later. (For more information, visit the following Microsoft Web site:http://www.microsoft.com/mscorp/java/)
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/mscorp/java/
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.0 and later (http://www.microsoft.com/mscorp/java/) and the following Knowledge Base article:
175622 PRB: SecurityExceptionEx Exception Running a Java Applet
HTML Tags
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>
If you wish to use the Package Manager, you need to use the applet tag with the Useslibrary parameter. The Package Manager feature is available in Internet Explorer 4.0 and later versions.
<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>
If you wish to deploy JAR files with Netscape Communicator 4.0, you need to use applet tag with the archive parameter:
<APPLET
code="MyApplet"
width=200
height=200>
archive="test.jar">
<PARAM NAME="ApplicationClass" VALUE="mycompany.MyApplet">
<PARAM NAME=... VALUE=...>
</APPLET>
If you wish to fully optimize performance on Internet Explorer 3.x, Internet Explorer 4.x and Netscape Communicator, you can combine the tags as in the example below.
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>
NOTE: If you have a complex set of tags, you may want to sniff the user agent string to determine the client being used. For example since the package management functionality is not supported in Internet Explorer 3, you may want to determine the version number of the browser as in the example below:
<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 support information about Visual J++ and the SDK for Java, visit the following Microsoft Web site:
Keywords: kbhowto kbcommandline KB179652
