★ wanayoo — archive 1999 http://java.sun.com/security/signExample12/Nouvelle recherche | Portail wanayoo

JDK 1.2 - Signed Applet Example

This example shows how a signed applet may be run in two different environments.

In addition, you may want to explore how to create your own keypairs and signed applets .

Running signed applets with the Java Plug-in

  1. Install the latest version of the Java Plug-in

    2. To follow this example, you'll need to download and install the Java Plug-in.

    Note that the Plug-in is already bundled with the Windows version of JRE 1.2, i.e., there is no separate download for the Plug-in for Windows: When you install the Windows version of JRE 1.2, the Plug-in gets installed automatically.

    On Solaris, you need to install the Plug-in separately, however.

  2. Observe the restrictions placed on applets by default

    3. Downloaded applets are prevented from writing files to your hard disk.

    Here's the source code for an applet that wants to do just that. It tries to write to the file /tmp/foo (or C:\tmpfoo, if you're on a Windows system.) This is not a malicious applet, but it is trying to do something that the Java Applet Security Manager prevents it from doing.

    Visit this URL: 

    	http://java.sun.com/security/signExample12/signedPluginEx.html
    from your browser.

    On the signedPluginEx.html page, the applet display should read "writeFile: caught security exception." This is a good thing, and the expected behavior. A security exception doesn't mean that a security violation occurred - it means exactly the opposite. It means that the system caught the applet trying to escape the restrictions of the applet sandbox. To alert you to that fact, the system throws an exception. This is programmer terminology for "the system set off a warning bell." When you see a security exception on a Java system, you know that the system prevented the code from violating security.

    Note that a "Java Console" window should have popped up from your browser, and it should have displayed some output, including the location of the User home directory. This is important information that you should remember for the next step.

  3. Set up your system to grant required permission

    4. It turns out that Duke (our mascot) signed this applet and stored it in an archive named signedWriteFile.jar. If you get a copy of Duke's certificate and import it into your system's keystore (by which you declare Duke's public key to be trusted) and configure your system policy to grant code signed by Duke and downloaded from the Java Software website to write to the specified file, then the applet will be allowed to create a file on your local filesystem.

    Here are the steps you need to take to accomplish that.

    1. Get a copy of Duke's certificate and store it in a file named Duke.x509

    2. Import this certificate into your 1.2 keystore under the alias name "Duke". If you do not already have a keystore, this command will automatically generate one for you. You will be prompted to see if you want to import the certificate into your keystore. Your keystore is by default stored in a file named .keystore in your home directory, as determined by the "user.home" system property. 
      	% keytool -import -alias Duke -file Duke.x509

    3. Download the policy file that will grant code signed by Duke and downloaded from the Java Software website to write to your local filesystem.

      The policy files were generated automatically using policytool.

    4. Make sure your keystore and policy files are in the directory where the Plug-in expects them to be. Your keystore and policy files should be in the User home directory that was displayed as part of the output in the Java Console. Your keystore and policy are expected to be in files named .keystore and .java.policy, respectively. If your keystore and policy files do not already reside in that directory, copy them there (make sure you save any existing keystore or policy files in that directory!).

  4. Exit and restart your browser

  5. Run the applet signed by Duke

    6. Now go ahead and run the applet signed by Duke. You'll notice that it can now create and write a file on your local filesystem. Visit this URL from your browser, after you've imported Duke's certificate: 
    	http://java.sun.com/security/signExample12/signedPluginEx.html

    You might wonder, what does the HTML tag look like, for a signed archive loaded by a plugin? The HTML is complicated, but, you don't need to write this HTML by hand. When you downloaded the Java Plug-In, you also could download a tool called the Java Plug-In HTML Converter. It's very easy to run. Once you've installed it, invoke the simple GUI tool: 

    	% java HTMLConverter
    Type in the name of the HTML file you need to convert so that it can be loaded by the Plug-In, and click on the "Convert" button.

    That's all there is to it. For more details on the object HTML tag, see the Java Plug-in HTML Specification.

Running signed applets with appletviewer

  1. Step 1 - Get the latest version of JDK 1.2

    2. To follow this example, you'll need to download a copy of JDK 1.2.

    Once you've downloaded JDK 1.2 and installed the software on your client, we're ready to go. Make sure that the JDK tools are accessible from your search path. We'll need to use these tools:

  2. Step 2 - Observe the restrictions placed on applets by default

    3. Downloaded applets are prevented from writing files to your hard disk.

    Here's the source code for an applet that wants to do just that. It tries to write to the file /tmp/foo (or C:\tmpfoo, if you're on a Windows system.) This is not a malicious applet, but it is trying to do something that the Java Applet Security Manager prevents it from doing.

    You can see what happens when you try to run this applet by typing this command in a shell window (or in an MS-DOS prompt window:) 

    % appletviewer http://java.sun.com/security/signExample12/signedWriteFile.html
    You should see that the system throws a security exception. This is a good thing, and the expected behavior. A security exception doesn't mean that a security violation occurred - it means exactly the opposite. It means that the system caught the applet trying to escape the restrictions of the applet sandbox. To alert you to that fact, the system threw an exception. This is programmer terminology for "the system set off a warning bell." When you see a security exception on a Java system, you know that the system prevented the code from violating security.

  3. Step 3 - Set up your system to grant required permission

    4. It turns out that Duke (our mascot) signed this applet and stored it in an archive named signedWriteFile.jar. If you get a copy of Duke's certificate and import it into your system's keystore (by which you declare Duke's public key to be trusted) and configure your system policy to grant code signed by Duke and downloaded from the Java Software website to write to the specified file, then the applet will be allowed to create a file on your local filesystem.

    Here's the steps you need to take to accomplish that.

    1. Get a copy of Duke's certificate and store it in a file named Duke.x509

    2. Import this certificate into your 1.2 keystore under the alias name "Duke". If you do not already have a keystore, this command will automatically generate one for you. You will be prompted to see if you want to import the certificate into your keystore. Your keystore is by default stored in a file named .keystore in your home directory, as determined by the "user.home" system property. 
      	% keytool -import -alias Duke -file Duke.x509

    3. Download the policy file that will grant code signed by Duke and downloaded from the Java Software website to write to your local filesystem.

      Both files were generated automatically using policytool.

  4. Run the applet signed by Duke

    5. Now go ahead and run the applet signed by Duke. Your keystore and policy are expected to be in files named .keystore and .java.policy, respectively, in your home directory, as determined by the "user.home" system property. If you do not want to store the policy file in your home directory (because you may already have a policy file there), you can specify the location of the policy at the command line, as shown below: 
    % appletviewer http://java.sun.com/security/signExample12/signedWriteFile.html

or

% appletviewer -J-Djava.security.policy="policy_file_location" http://java.sun.com/security/signExample12/signedWriteFile.html

    You'll notice that the applet can now create and write a file on your local filesystem.

    You might wonder, what does the HTML tag look like, for a signed archive? 

     
<applet code=writeFile.class archive="signedWriteFile.jar" width=500 height=50>
</applet>

    That's all there is to it. You simply tell the browser the name of the archive, using the archive= attribute. For more details on the applet HTML tag, see the JAR Guide.

Creating Keypairs and Signed Applets

Here's a script that encapsulates all the steps you need to take to generate your own keypair and sign a Java Archive (JAR) file. Refer to it as an example, as you experiment with the new features of JDK 1.2.

To create your own signed JAR file, you need to run these additional tools:

doit: A script that creates a Duke identity with a signature keypair and certificate, and then creates an archive and signs it. It prints out some diagnostic information, such as the contents of the signed archive, and the contents of the keystore.

Useful links

Here are links to all the files used in this example.

For more information, refer to the documentation on our main security page for JDK 1.2, http://java.sun.com/products/jdk/1.2/docs/guide/security. In particular you might be interested in the Summary of JDK 1.2 Security Tools.

java-security@sun.com
Last modified: Fri Feb 5 14:26:11 PST 1999