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
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>