Message-Id: <199904162108.OAA05908@laguna.eng.sun.com>
Date: Fri, 16 Apr 1999 14:08:10 -0700 (PDT)
From: Jan Luehe <luehe@laguna.eng.sun.com>
Subject: Re: Comments on your Signed Applet Example
To: java-security@java.sun.com, michael@haertfelder.com
Michael:
> I visited, downloaded and tried out your Signed Applet Example number 12 from
> page
> http:///204.160.241.19/security/signExample12/
> under Windows NT 4 with Netscape 4.5 and JRE1.2
> After all it doesn't work.
I just ran the example myself, and it worked.
Are you sure you copied the .java.policy into your home
directory, and created a keystore file (into which
you imported Duke's certificate) in that directory?
> Yes, I imported successfully Duke's certificate (I verified that)
> Yes, I installed JRE1.2 successfully (I've used the plugin successfully some
> other examples)
> Yes, I copied .java.policy to my home directory.
>
> It remains the following questions:
> 4.) How is the chronology of using the files ? Suggestion:
> (1) retrieving html pages
> (2) retrieving the jar file mentioned in the applet part of that page
> (3) the applet tries to write to a file -> exception
> (4) the RunTimeEnvironment looks in the local policy file if the jar file
> is listed ->YES
> (5) the RunTimeEnvironment looks in the local keystore file for the
> certificate of the jar archive
> (6) the RunTimeEnvironment verifies that the found certificate in the
> keystore is the same as the certificate of the jar archive
> (7) If same grant write access to the java applet
When the applet classloader loads the applet jar file, it verifies
the jar file signature and constructs the applet's
codesource, which contains 2 pieces of information: a codebase
(this is the location where the applet came from), and the certificate
(chains) of who signed the applet.
Then the classloader checks the configured security policy to see
which permissions are granted to that particular codesource.
(The alias name in the policy is replaced with the corresponding certificate
from the keystore specified at the top of the policy file.)
The applet's codesource and the permissions granted to it form
the protection domain to which the applet classes belong.
This information is used by the access controller when making
access control decisions.
See
http://java.sun.com/products/jdk/1.2/docs/guide/security/
for more information about the access control algorithm.
> If the scheduling above is correct this would be very uncomfortable because I
> need TWO !!! files (Certificate+policy) to run the applet.
This is correct. However, we will be working on some mechanisms
that will allow you to make trust decisions without having to
preconfigure your keystore and policy files.
Jan