Rich Internet Application Deployment Process

Java Rich Internet Applications Guide > Security > Rich Internet Application Deployment Process

This page includes the following topics:

Overview

When a user launches an applet or a Java Web Start application, collectively called Rich Internet Applications (RIAs), a number of checks are made to determine if the RIA is allowed to run, which version of the JRE is used, and which security prompts are shown to the user. The purpose of this topic is to explain those checks and show how the decisions are made.

The following flow chart shows a simplified version of the process that is used to deploy a RIA.

Figure 1. Deployment Processing Flow Chart

Flow chart that shows the deployment process for RIAs

The nodes in the left column of the chart provide a high-level view of what happens after a user starts a RIA. The following steps describe the main process. When a decision is made to either run or block the RIA, any remaining steps are skipped.

Begin loading Java content.

When a user opens an HTML page that contains an applet, or starts a Java Web Start application, the content starts to load. If no JRE is installed, the browser notifies the user that the plug-in is missing and the RIA is not run.
Is the browser plug-in registered and allowed to run?

Check that the plug-in is registered and enabled. See Plug-in Processing for more information.
Does a rule exist for this RIA?

If a deployment rule set exists, then look for a rule that matches the RIA. If a matching rule is found, then the action for the rule is taken. If the action is block, then the RIA is not run. If the action is run, then the RIA is allowed to run. If no rule is found, or the action is default, then the deployment process continues with the next step in the flow chart. See Rules Processing for more information.
Is the JRE expired or below the security baseline?

Ensure that a valid JRE is installed to run the RIA. If not, then give the user the option to update the JRE. See JRE Status for more information.
Does the RIA have a valid signature?

Check if the RIA is signed. If so, then ensure that the signature is valid. See Digital Signature for more information.
Which security prompt is needed?

Determine which security prompt to show based on the RIA, the setting of the security level in the Java Control Panel, and the exception site list. If an older JRE is requested, then choose the JRE that is used to run the RIA. See Security Prompts for more information.

Plug-in Processing

When content starts to load, plug-in processing answers the question in the second step of the deployment process, "Is the browser plug-in registered and allowed to run?" This process is shown in the Plug-in Processing box in Figure 1, which is connected to the node for this step and shown to the right of the node.

If the plug-in is not registered, then the browser notifies the user that the plug-in is missing and the RIA is not run.

If the plug-in is registered, then deployment properties are checked to see if the plug-in is disabled. The browser is also checked to see if the browser has disabled the plug-in. If the plug-in is disabled, then the user is notified and the RIA is not run. If the plug-in is enabled, then the deployment process continues with Rules Processing. See the Security tab of the Java Control Panel for information on disabling and enabling the Java Plug-in. If the plug-in was disabled by the browser, see the documentation for the browser.

Rules Processing

Rules processing answers the question in the third step of the deployment process, "Does a rule exist for this RIA?" This process is shown in the Rules Processing box in Figure 1, which is connected to the node for this step and shown to the right of the node. Rules processing looks for a valid Deployment Rule Set file. See Deployment Rule Set, which was introduced in Java 7 update 40, for information on this feature.

If no deployment rule set is found, then the deployment process continues with JRE Status.

If an invalid deployment rule set is found, then an error message is shown to the user and the RIA is blocked.

If a valid deployment rule set is found, then one of the following actions is performed:

If no rule matches the RIA, then the deployment process continues with JRE Status.
If the RIA matches a rule, then one of the following actions is performed:
- If the rule allows the RIA to run, then the signature for the RIA is checked. If the signature is valid, or the RIA is unsigned, then the RIA is run on the requested version of the JRE without showing any security prompts. If the signature for the RIA is not valid, then a security warning is shown to the user and the RIA is blocked.
  
  For rules processing, a signature that contains a certificate that is expired or a certificate whose certificate revocation status cannot be checked is considered valid, and the RIA is run. An invalid signature is one that contains a certificate that is blacklisted, revoked, or malformed in some way.
- If the rule blocks the RIA, then a security warning is shown to the user and the RIA is blocked.
- If the rule requests default processing for the RIA, then the deployment process continues with Digital Signature.

JRE Status

JRE status processing answers the question in the fourth step of the deployment process, "Is the JRE expired or below the security baseline?" This process is shown in the JRE Status box in Figure 1, which is connected to the node for this step and shown to the right of the node. If the option for ignoring the security baseline is set, then the JRE status is not checked and the deployment process continues with Digital Signature. The deployment property deployment.expiration.check.enabled is used to indicate if the security baseline is ignored. See Deployment Configuration File and Properties for information on this property.

If the security baseline is not ignored, the JRE is checked to see if it is expired or below the security baseline. If neither condition is true, then the deployment process continues with Digital Signature. See Setting the Security Level of the Java Client for information on the JRE expiration date. See the Update Release Notes for your version of the JDK for information on the security baseline.

If the JRE is either expired or below the security baseline, the user is given the option to update the JRE. Depending on the user's choice, one of the following actions is performed:

If the user chooses to update later, then the deployment process continues with Digital Signature.
If the user chooses to block the RIA, then the RIA is not run.
If the user chooses to update the JRE, then the user is directed to the download page at java.com.

Digital Signature

Digital signature processing answers the question in the fifth step of the deployment process, "Does the RIA have a valid signature?" This process is shown in the Digital Signature box in Figure 1, which is connected to the node for this step and shown to the right of the node. If the RIA is unsigned, then the deployment process continues with Security Prompts.

If the RIA is signed, then the certificate used to sign the RIA is validated. If the certificate is invalid or revoked, then the RIA is blocked.

If the RIA is signed with a valid certificate, or if the certificate is expired or the revocation status cannot be checked, then the deployment process continues with Security Prompts. The action taken for RIAs that have expired certificates or certificates that cannot be checked depends on the setting of the Security Level slider in the Java Control Panel.

See Signing and Verifying JAR Files for information on digital signatures.

Security Prompts

The final step in the deployment process is to determine if the RIA is run, and answers the question in the last step of the deployment process, "Which security prompt is needed?" If the RIA is run, this step also determines which version of the JRE is used when an older version is requested. The Normal Processing box and Exception Site List box in Figure 1 show the process for determining if the RIA is run and which security prompt is shown. These boxes are connected to the node for this step and shown to the right of the node.

The process for determining which JRE is used when an older version is requested is shown in the Select JRE box in Figure 1, which is connected to the boxes for determining if the RIA is run and which security prompt is shown.

At this point in the process, the decision to run or block the RIA, and the choice of the security prompt to show, is based on the following criteria:

The setting of the Security Level slider in the Java Control Panel, the default is High. See the Security tab of the Java Control Panel for information on the Security Level Slider.
The presence of a signing certificate for the RIA
The status of the certificate that was used to sign the RIA
The inclusion of the location of the RIA in the exception site list

Note: If the user previously selected the option to not show a prompt again, then that prompt is suppressed. The response the user gave when the option to suppress was selected is used instead of showing the prompt again.

Normal Processing

The following table shows if a RIA is run or blocked when the location of the RIA is not on the exception site list.

Security Level	Run with Prompt	Block
Very High	Only RIAs that are signed with a valid certificate located in the Signer CA keystore are allowed to run. The manifest for the main JAR file for the RIA must contain the Permissions attribute. See JAR File Manifest Attributes for Security for information on the Permissions attribute.	The following RIAs are blocked: Signed with an expired certificate, or a certificate whose revocation status cannot be checked Missing the Permissions attribute in the main JAR file Self-signed (signed with a certificate that is not in the Signer CA keystore) Unsigned Local
High	RIAs that are signed with a valid certificate located in the Signer CA keystore, an expired certificate, or a certificate whose revocation status cannot be checked are allowed to run. The manifest for the main JAR file for the RIA must contain the Permissions attribute. See JAR File Manifest Attributes for Security for information on the Permissions attribute.	The following RIAs are blocked: Missing the Permissions attribute in the main JAR file Self-signed (signed with a certificate that is not in the Signer CA keystore) Unsigned Local
Medium	All RIAs are allowed to run.	No RIAs are blocked.

Security Level

Run with Prompt

Block

Very High

Only RIAs that are signed with a valid certificate located in the Signer CA keystore are allowed to run. The manifest for the main JAR file for the RIA must contain the Permissions attribute. See JAR File Manifest Attributes for Security for information on the Permissions attribute.

The following RIAs are blocked:

Signed with an expired certificate, or a certificate whose revocation status cannot be checked
Missing the Permissions attribute in the main JAR file
Self-signed (signed with a certificate that is not in the Signer CA keystore)
Unsigned
Local

High

RIAs that are signed with a valid certificate located in the Signer CA keystore, an expired certificate, or a certificate whose revocation status cannot be checked are allowed to run. The manifest for the main JAR file for the RIA must contain the Permissions attribute. See JAR File Manifest Attributes for Security for information on the Permissions attribute.

The following RIAs are blocked:

Missing the Permissions attribute in the main JAR file
Self-signed (signed with a certificate that is not in the Signer CA keystore)
Unsigned
Local

Medium

All RIAs are allowed to run.

No RIAs are blocked.

If the RIA is allowed to run and requests an older version of the JRE, then the deployment process continues with Select JRE.

Exception Site List

The Exception Site List feature, which was introduced in Java 7 Update 51, provides a way for users to run RIAs that would be blocked because they do not meet the current security requirements. RIAs that are launched from sites in the exception site list are allowed to run with the appropriate security prompts. See Exception Site List for more information on this feature.

If the RIA is allowed to run and requests an older version of the JRE, then the deployment process continues with Select JRE.

Select JRE

It is recommended that the most recent version of the JRE always be used. However, if a RIA is not compatible with this version of the JRE, the version that is required to run the RIA can be requested in the JNLP file or applet tag.

When an older version is requested, one of the following actions is performed, based on the criteria described in the sections that follow:

The RIA is restarted with the requested version of the JRE using Secure Static Versioning (SSV).
The RIA is run with the latest version of the JRE that is installed.
The RIA is blocked.

Run the RIA with the Requested JRE

The RIA is restarted with the requested version of the JRE using SSV when the following conditions are met:

RIA is signed.
The requested version of the JRE is installed.
For privileged RIAs, which request all permissions, the RIA is signed with a valid certificate.
For sandbox RIAs or self-signed RIAs, the user agrees to run with the requested version when prompted.

Run the RIA with the Latest JRE

The following table describes the cases in which the RIA is run with the latest version of the JRE that is installed, instead of the requested version.

Signing Status	Requested Version is Installed	Type of RIA	Response to Prompt
Signed	Yes	Sandbox, self-signed	User does not agree to run with requested version
Signed	No	All	User agrees to run with the latest version that is installed
Unsigned	Ignored	All	User agrees to run with the latest version that is installed

Block the RIA

The RIA is blocked in the following cases when the user does not agree to run with the latest version of the JRE that is installed:

The RIA is signed and the requested version of the JRE is not installed.
The RIA is unsigned.