Documentation Contents
Java Platform, Standard Edition Deployment Guide
Contents    Previous    Next

22 Rich Internet Application Deployment Process

This topic describes the steps in the deployment process that are used to determine if a Java or JavaFX application is allowed to run in the browser or be started from a browser. This process does not apply to standalone or self-contained applications.

When a user launches a Java or JavaFX application that is embedded in a browser or is started from a browser, 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.

This topic includes the following sections:

22.1 Overview of the Process

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

Figure 22-1 Deployment Processing Flow Chart

Description of Figure 22-1 follows
Description of "Figure 22-1 Deployment Processing Flow Chart"

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

22.2 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 22-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 Section 18.4, "Security" in Chapter 18, "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.

22.3 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 22-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 Chapter 26, "Deployment Rule Set" 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:

22.4 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 22-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 Chapter 19, "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 Section 21.1, "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:

22.5 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 22-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 certificates that cannot be checked depends on the setting of the Security Level in the Java Control Panel.

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

22.6 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 22-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 22-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:

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.

22.6.1 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 Chapter 24, "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, 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 Chapter 24, "JAR File Manifest Attributes for Security" for information on the Permissions attribute.

The following RIAs are blocked:

  • Signed with an expired certificate

  • 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


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

22.6.2 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 Chapter 27, "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.

22.6.3 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.

22.6.3.1 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.

22.6.3.2 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


22.6.3.3 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.

Contents    Previous    Next

Oracle and/or its affiliates Copyright © 1993, 2014, Oracle and/or its affiliates. All rights reserved.
Contact Us