|
Java™
by example!
|
|
|
How do I control permissions with a JApplet?
It is important that you have installed the JRE1.3 on your machine, that includes the Java 1.3 plug-in.
An JApplet runs by default in a security sandbox, an environment where it has no permission to do anything that might harm the client's machine.
Consider the following applet.
WriteFile.java:
WriteFile.html (generated with Sun's HTMLConverter tool):
When you run this JApplet, you'll get a security exception.
Check it out for yourself at http://www.esus.com/applets/WriteFile.html.
So what do we need to do to make this work?
You will have to explicitely give access to that applet to use resources it is normally not permitted to. To do so, one requirement is to sign our applet. The following procedure shows you how to sign an applet. You will need to have a certificate, either one you create yourself (a self-signed applet) or one that you have bought from a certificate authority like VeriSign or Thawte. For now, I'll create one myself.
Create a certificate with keytool (JDK tool introduced in JDK1.2.2):
(Note: if you haven't used keytool before, just make up a password) Here we have created a RSA key with the name esustest. Now look in your home directory, a file should have been created called .keystore:
To see that the key has been added to the store:
Now let's create a JAR file from our applet:
The jar has been created:
Now we can sign that JAR file with our generated keypair as follows:
Notice the size of our original JAR and the new digitally signed JAR! We can verify the JAR as follows:
Notice the files that have been added to the JAR file:ESUSTEST.SF and ESUSTEST.RSA. SF stands for Signature File and it includes the filename (WriteFile.class), the name of the algorithm used (RSA) and the digest value. Test it out for yourself:
The other file that has been added to the JAR is ESUSTEST.RSA. This is the Signature Block File It contains the certificate or certificate chain.
Now we're ready to deploy our signed applet and see if that changed the situation. Let's first modify our HTML file so that it uses the JAR file instead of the class file.
WriteFile2.html:
Upload the files to your webserver and try it out! You can also try it out here:
http://www.esus.com/applets/WriteFile2.html.
With both Netscape and IE, you'll get the following window:
Hmm, it doesn't really create a file, does it? Well, earlier version of the plug-in (JDK1.2.2) would actually ask you if you want to grant extra permissions. But from the 1.3 plugin onwards, self-signed applets (like our WriteFile.jar) will need extra work! If you would have signed your applet with a certificate you bought from a recognized standard root CA, like VeriSign or Thawte, the browser would ask you if you want to grant additional permissions. Check out http://java.sun.com/products/plugin/1.3/docs/nsobjsigning.html!
Just like anyone else, I don't have no money :) So for the time being, I won't buy such a certificated from a trusted CA. But I'll show you a way to have your applet run anyway (useful for testing purposes). It is important to realize that in order to do so, you must have access to the client's machine(s) onto which you want to deploy your applet.
What happens when you download a signed applet is this: the browser downloads the JAR file and checks whether it is signed. If it is, it will check the security policy configuration file whether the "usePolicy" RuntimePermission is set. There are two policy files, a system-wide one, (JRE_HOME/lib/security/java.policy) and a user specific one (USER_HOME/.java.policy). In my case, my system-wide one is at C:\Program Files\JavaSoft\JRE\1.3.1\lib\security and my user one is at C:\Windows\.java.policy. When the plug-in starts, it will concatenate both of them together and use them as a security policy for the rest of the session. If the usePolicy permission is set, security is controlled based on the permissions that are set in the policy files, even if you have an RSA signed applet signed by a trusted authority that wants full control over your client's machine. This allows you to have finer-grained security control over what your signed applets are able to do.
Let's change our policy file to grant the permission to write to the local file c:\esusfoo. Add the following lines of code to your .java.policy file:
and test out http://www.esus.com/applets/WriteFile2.html again.
You get the following error:
Click OK, the file will be created anyway, since you granted that permission explicitely in your policy file.
To get rid of that annoying error, define the extra permission "usePolicy" in your policy file:
Try out the applet again! No errors!
Let's modify the applet a bit so that it also tries to write to a file c:\esusfoo2. The new applet look like this.
WriteTwoFiles.java:
Sign the jar file as described above:
WriteTwoFiles.html:
If you run this signed applet (http://www.esus.com/applets/WriteTwoFiles.html), using the same modified policy file, esusfoo was successfully accessed but, a AccessControlException is thrown in accessing esusfoo2, as expected.
One more problem: the extra permissions to write to esusfoo and esusfoo2 are granted to all applets. You can fine-tune your policy configuration file with signedBy and/or codeBase. With signedBy, you can specify the keystore entry that contains the public key so that verification of the signed JAR file is possible. The runtime system then verifies the association of the private key with which the JAR file was signed with the public key of the specified entry in the keystore. codeBase specifies that the permissions in this grant entry are only applicable to signed applets coming from a particular code source.
Because we're using a self-signed applet, we need to import our certificate in the keystore of the plug-in. The following steps show you how to:
- export the certificate to a file:
- copy esustest.cer to the directory that contains the file cacerts:
- make a backup of cacerts:
- import the certificate into the cacerts keystore:
(Note: the initial password for the cacerts file is changeit as specified in the documentation)
Our self-signed certificate is now added to our database.
Run WriteTwoFiles again. Notice that now you'll get the following dialog box:
This dialog box would also show up if your applet was signed by a certificate assigned by a VeriSign or Thawte type trusted CA.
Now change to policy file for more fine-grained control:
Further Information
Author of answer: Joris Van den Bogaert
Comments
Comments to this answer are only viewable by members. Login or become a member!
|
|
|
|
|
In-house 
