The JAR file manifest contains information about the contents of the JAR file, including security and configuration information. Use the manifest attributes described in this section to enhance the security of running RIAs from a browser. Add the attributes to the manifest before the JAR file is signed. See Modifying a Manifest File in the Java Tutorial for information on adding attributes to the JAR manifest file.
Permissions attribute is used to verify that the permissions level requested by the RIA when it runs matches the permissions level that was set when the JAR file was created. This attribute is required in the manifest of the main JAR file for the RIA, secondary JAR files and extensions are not required to have the
Permissions attribute. If the attribute is not present in the main JAR file, then the RIA is blocked.
Permissions attribute to help prevent someone from re-deploying an application that is signed with your certificate and running it at a different privilege level. Set this attribute to one of the following values:
sandbox - Indicates that the RIA runs in the security sandbox and does not require additional permissions.
all-permissions - Indicates that the RIA requires access to the user's system resources.
For Java Web Start applications and applets that use JNLP, the value of the
Permissions attribute must match the permissions level requested in the JNLP file, or match the default permission if no permissions level is requested. Otherwise, an error is shown and the RIA is blocked. See Structure of the JNLP File for information on the
security element that is used to request the permissions level. If the element is not present, the permissions level defaults to
For applets that do not use JNLP, the value of the
Permissions attribute must match the permissions level requested in the applet tag. Otherwise, an error is shown and the RIA is blocked. If the applet tag does not contain a permissions level, then signed applets run with the permissions level set by the
Permissions attribute. See Deploying with the Applet Tag for information on setting the permissions level in the applet tag.
Codebase attribute is used to restrict the code base of the JAR file to specific domains. Use this attribute to prevent someone from re-deploying your application on another website for malicious purposes.
Note: If the
Codebase attribute does not specify a secure server, such as
HTTPS, some risk exists that your code could be repurposed in Man-in-the-Middle (MITM) attack schemes.
Set this attribute to either the domain name or IP address where the JAR file for the application is located. The protocol and port number can also be included. For multiple locations, separate the values with a space. An asterisk (*) can be used as a wildcard only at the beginning of the domain name, and cannot be used with only a top-level domain, such as *.com. The following table shows sample values and what they match.
Does Not Match
The value of the
Codebase attribute must match the location of the JAR file for the RIA. Otherwise, an error is shown and the RIA is blocked. If the attribute is not present, a warning is written to the Java Console and the code base specified for the applet tag or JNLP file is used.
Application-Name attribute is used in security prompts to provide a title for your signed RIA. Use of this attribute is recommended to help users make the decision to trust and run the RIA. The value can be any valid string, for example:
Application-Name: Hello World
Application-Name attribute is not present in the JAR file manifest, a warning is written to the Java Console and the value for the
Main-Class attribute is used. If neither attribute is present in the manifest, no title is shown in the security prompts. Titles are not shown for unsigned RIAs.
Application-Library-Allowable-Codebase attribute identifies the locations where your signed RIA is expected to be found. This attribute is used to determine what is listed in the Location field for the security prompt that is shown to users when the JAR file for your RIA is in a different location than the JNLP file or HTML page that starts your RIA. If the files are not in the locations identified, the RIA is blocked. Set this attribute to the domains where the JAR file, JNLP file, and HTML page are located. To specify more than one domain, separate the domains by a space, for example:
Application-Library-Allowable-Codebase: https://host.example.com *.samplehost.com
Application-Library-Allowable-Codebase attribute is present and matches the location from which the RIA is started, then a single host is listed in the Location field for the prompt and the option to hide future prompts is provided. If this attribute is present and the files are accessed from a location not included for the attribute, then the RIA is blocked. If this attribute is not present, then multiple hosts that correspond to the locations of the JAR file and the JNLP file or HTML page are listed in the Location field for the prompt. When multiple hosts are shown, the user is not given the option to hide future prompts. Use of this attribute is recommended so the files for the RIA are accessed only from known locations.
This attribute is not needed if the JAR file for the RIA is in the same location as the JNLP file or HTML page that starts the RIA.
See Codebase Attribute for a description of the values that are allowed.
Caller-Allowable-Codebase attribute, the call is blocked. To specify more than one domain, separate the domains by a space, for example:
Caller-Allowable-Codebase: host.example.com 127.0.0.1
See Codebase Attribute for a description of the values that are allowed. If a stand-alone asterisk (*) is specified as the value for the
Trusted-Only attribute is used to prevent untrusted classes or resources from being loaded for an applet or application.
Set the value of the attribute to
true, for example:
This attribute prevents a privileged application or applet from being repurposed with untrusted components. All classes and resources in the application or applet must be signed and request all permissions.
Trusted-Library attribute is used for applications and applets that are designed to allow untrusted
components. No warning dialog is shown and an application or
applet can load JAR files that contain untrusted classes or
resources. Set the value of the attribute to
true, for example:
This attribute prevents components in a privileged application or applet from being repurposed with untrusted components. All classes and resources in a JAR file containing this manifest attribute must be signed and request all permissions.
In a mixed code application or applet, all privileged classes and
resources must be included in JAR files that contain the
All trusted library JARs are loaded into a separate dedicated class
loader that is unique to the application or applet instance. This
Trusted-Library loader is now the parent of the
normal Web Start or applet class loader. For backwards
compatibility with the original search order, both loaders
cooperate to implement a common class path. Consistent with prior
releases, JAR files use lazy download and are opened as needed to
find requested classes and resources.
Code in a JAR file that is to be marked with the
Trusted-Library manifest attribute may need to be
modified slightly if it uses calls that are class loader dependent,
such as the single parameter version of
Class.getResourceAsStream(), some variants of
java.util.ResourceBundle.getBundle(), and any other
methods that operate relative to their immediate caller's defining
loader. Changes only need to be made if the requested class or
resource might be found in a JAR file that is not a
Trusted-Library (and is therefore loaded by the normal
Web Start or applet class loader).
Code in a
Trusted-Library can look up the normal
loader by invoking
however, that there are uncommon circumstances in which
getContextClassLoader() may return
For example, this may happen when the garbage collector uses a JRE
system thread to invoke the
of an unreachable instance.
If you need to convert class to
Class.getResourceAsStream() to their
ClassLoader equivalents, remember to adjust the string
parameter as described by the documentation for those two methods.
If the original resource name began with
'/', then it
was an absolute name and the leading
'/' simply needs
to be removed. Otherwise, determine if the class instance which was
the target of the
getResource call is in a named
package. If it is an array you should first determine the
underlying component type of the array. Invoke
Class.getName() on the class or component type
instance. If the class name contains any
characters, it is in a named package that will need to be prepended
to the original resource name. Determine the package name by
removing any characters after, and including, the trailing
'.' character. Next, replace any remaining
'.' characters with
Finally, add a trailing
'/' and append the original
resource name string. This new string can now be passed to the
ClassLoader version of the
Generally, care must be taken to ensure that the code in the trusted library is written in a careful and secure manner and is otherwise compatible with being loaded in a separate class loader instance from any remaining jars that are part of the application and are loaded by the normal loader.
See Mixing Privileged Code and Sandbox Code for information on using manifest attributes to manage calls from untrusted code.
See Preventing RIAs from Being Repurposed for information on using manifest attributes to ensure that the correct permissions level and code base are used.
For information on adding attributes to the JAR manifest file, see Modifying a Manifest File in the Java Tutorial.