How do I extend permissions to an applet without editing the policy file manually?

Lennart Jorelid



A: Short answer: Forget about Java 2 security (i.e. the policy file) when creating applets. No major web browser currently supports that security model. Instead, place the applet in a signed JAR file, and make sure the signature of the JAR is in the trusted Certificate Hierarchy of the web browser.

Longer answer: Applet security is a very tricky subject, since each web browser has its own way of handling security and certificates. Essentially, you will have to know which web browser loads the applet, to provide the correct packaging (JAR or CAB file). Although all web servers may determine the browser flavor easily, creating a privileged applet within the properly signed container is a hairy matter - mainly because the two major web browsers handle security privileges very differently. I will therefore divide my answer in three parts: general certificate handling in web browsers, Netscape and Internet Explorer.

How do Certificates work?

A certificate consists of some unique identification data (such as a public key, X.509 distinguished name, Unix UID, email, drivers license, fingerprint, etc.) that has been digitally signed by someone trustworthy. Most security application developers consider a Certificate Authority or CA to be a trustworthy entity - in fact, the major role of a CA is to be able to verify the unique identity of someone who has received a certificate from the CA through purchase or other means. The tool for handling such verification is a key pair (see "Asymmetric cryptography" for a full explanation), used to verify that personal information data has not been altered. 

A certificate contains 2 major parts; personal data and data from the issuer (CA). The certificate issuer essentially guarantees that a certain certificate has been issued to a specific entity (individual, organization or piece of code). A root certificate is a certificate signed by the same entity that created it:


Certificate type  Description  Structure Graphic  Stylized Graphic 
Normal certificate  ID data of an entity; validity guaranteed by the certificate issuer, whose digital signature seals the certificate from unwanted future modification. Thus, the structure resembles a tree node, with the authorization link pointing to the certificate authority.
Root certificate  Normal certificate, except that the issuer and the id data description is identical. 


Alas, let us introduce the players in our scenario:


Name  Role  Need  Graphic 
jGuruCert Certificate Authority Verify the identity of each customer who has purchased a certificate 
Lennart Developer Create a signed/trusted application or applet
Terence Cubicle worker Purchase some goods online


We also require the introduction of at least two applications (more than these may be required for some scenarios).


Name  Role  Need  Graphic 
CoolBrowser Web Browser Make sure that an applet can be trusted before running any privileged code
CoolApplet Applet intending to execute on the JVM of the CoolBrowser Convince CoolBrowser of its privileged state and


Signed Applet creation and deployment

The process of creating and deploying an applet packaged in a signed archive is performed in 6 steps:

  1. Lennart (the developer) fills out a form with all data required by the CA to issue a certificate. The exact data may vary depending on the type of certificate that should be issued.



  1. The CA makes sure that the data given by Lennart is correct, and signs the data with their Private Key. The resulting data stream is known as a Certificate.



  1. A copy of the certificate is sent back to Lennart from the CA.



  1. Lennart creates the CoolApplet in his favorite development environment, packages it in an archive file.



  1. The archive file is signed with the digital certificate from (3).



  1. The digitally signed archive containing the CoolApplet is placed on a web site for download and usage

Signed applet usage

Each browser (including the CoolBrowser example) has its own way of handling certificates, but in most cases the purpose of certificate handling in a browser is to slacken the applet sandbox security restrictions. Most browsers therefore contains a certificate repository, contained within the browser software. Essentially, the browser user may grant permission to an applet to run privileged code if the user considers the issuer and developer of the applet archive certificate trustworthy. Some browsers are quite strict about its root repository certificates, and will not let the browser user add his or her own root certificates without much low-level tweaking.

Our CoolBrowser has a certificate repository which stores a couple of trust root certificates (certificates which are regarded as trusted by the browser). A trust root certificate can be used to promote trust for another certificate, such as described above. Thus, if the Coolbrowser repository contains a specific installed root certificate, and that certificate is also found on an applet archive, the identity of the developer archive is granted by the issuer of the certificate.

Running and granting privileges to a signed applet is a 4 step process:

  1. The archive containing the CoolApplet is referenced on a web page and thus downloaded into the browser for execution.



  1. Before permitting the applet to execute, CoolBrowser checks the archive file for certificates. Lennart's certificate is found.



  1. The authority/issuer section of Lennart's certificate is checked, and its contents matched against the currently stored browser certificates. A match is found, so the browser brings up a Dialog box querying the user for permission to lower the sandbox security restrictions. All the personal data of Lennart given in the certificate are displayed to the user. Thus, the user may choose to trust the developer for code quality and the CA for validation.



  1. The user grants the required permissions to the applet, which now runs privileged code outside of the standard sandbox.