JavaFX Technical Tips | Create a Secure JavaFX Application

Create a Secure JavaFX Application

Skill LevelIntermediate
Supported Versions JavaFX 1.3
Key Features JavaFX Deployment
Last Updated December 2009

This article provides insight on some of the basic Java and JavaFX concepts that you need to know when creating a secure JavaFX application.

Applet and Java Web Start Applications

Java Depending on your goal, you can create an applet or a Java Web Start application from your source code. In terms of security, the difference between the two is minimal and mostly in the way they are deployed.

An applet always starts from a browser, but as of Java 6 Update 10, you can drag some applets out of the browser (detach them) so that they run in their own window and continue to run after the browser is closed. A Java Web Start application is deployed through a browser only the first time. After the Java Web Start application is downloaded and after the user has accepted its security certificate, it behaves almost like a stand-alone application. Web Start applications can also be launched through the Windows Start menu or desktop icons.

JavaFX applets can be used for creating dynamic and interactive web pages. Applets are loaded over a network and can be embedded in a web page. When you want to add some dynamics to your page by using JavaFX technology, unsigned applets are a way to go. If you need more access to the user's local resources, such as storage of application data, explore some of the new features of JavaFX. These features enable you to make more powerful unsigned applets without compromising users' security, or you can sign your applet.

Security-Related JNLP Tags

To enable you to deploy your JavaFX application over the Internet, your IDE creates a JNLP descriptor file that is used when executing the application. Starting with Java 6 Update 10, Java Plugin technology provides support for launching both Java Web Start applications and applets directly from JNLP files. For more information see the JNLP Support in the New Java Plugin Technology article.

The JNLP file for a Java Web Start application contains the <security> tag that describes the application's security requirements. By default every application runs in a restricted execution environment, similar to the applet sandbox. The security element has two permission options: all-permissions, which provides full access to the client's local computing resources, j2ee-application-client-permissions, which provides a selected set of permissions defined for J2EE client applications including socket permissions, clipboard access permission, printing permission, and others. Before you settle on the full-access option, test your application with permissions defined by j2ee-application-client-permissions, which might be just enough to run your signed JavaFX application on the users' systems.

Source Code

...
<security> 
 <j2ee-application-client-permissions/> 
</security>
...

If you specify all-permissions, the application will request full access to the local system and network. Note that for applications requesting full access, you need to sign all JARs. The user will be prompted to accept the certificate the first time the application is launched, either for the current session or permanently.

For more information, refer to Java Web Start Guide.

Java Sandbox

sandbox One of the fundamental Java security concepts is the Java sandbox. The sandbox security model is an intrinsic part of the Java architecture. The sandbox is built into the Java Runtime Environment and the Java API.

The Java security model is focused on protecting users from hostile programs downloaded from untrusted sources across a network. To accomplish this goal, the Java Runtime Environment provides a "sandbox" in which Java programs run. A Java program must play only inside its sandbox. It can do anything within the boundaries of its sandbox, but it cannot take any action outside those boundaries. The sandbox for untrusted Java applets prohibits many activities, but starting with Java 6 Update 10 release, the boundaries have been expanded. For example, applets can now make HTTP network connections to other hosts, subject to the cross-domain policy on that host. See Cross-Domain XML Support for more information and current limitations.

The sandbox security model makes it easier to work with unsigned software. Instead of completely blocking any unsigned application, the sandbox model enables code to run from any source. But when code is running, the sandbox restricts the unsigned code from taking any actions that could possibly harm the user's system or resources. Unlike a signed application, users do not have to understand additional security warnings and do not need to decide whether they can or cannot trust the downloaded application. The sandbox itself prevents any malicious code from doing any damage.

Security on Mobile Devices

mobile Note: This article describes how Java ME security works in general. A future release of JavaFX Mobile will support the security policy layering on top of this Java ME (MSA) security model.

Most of the conceptual material of the desktop Java security applies to mobile Java, although many of J2SE features are not available directly on mobile devices.

The Java ME security model depends on the configuration: CDC uses a standard configuration of the security model of JavaSE, while CLDC uses the security model of MIDP.

In MIDP 2.0, security domains protect against unauthorized access of data, applications, unexpected network charges from untrusted applications, and other network and device resources by MIDlet suites on the device. Two security domains are on a mobile device:

Trusted or Identified
Untrusted or Unidentified (because the origin of the application can be authenticated by signing)

Unsigned MIDlet suites are not trusted, and are assigned to untrusted domains that restrict access to any privileged functionality. The application will work, but for each access to the API it will ask permission from the user. However, the user will have an option to allow access to the API for one time and for all subsequent calls. The permissions requested in the application descriptor (JAD file) allow the MIDlet access to APIs based on the policy for the domain. The policy for the domain is recommended but might vary by operator and device. The recommended policy typically still prompts for user confirmation at least once for each run of the application. None of the protected APIs is accessible without prompts. Certificates are used to identify a domain for the application. Depending on the implementation, sometimes new certificates can be added or existing certificates can be updated, and sometimes not.

That said, any JavaFX application that you create for mobile devices falls into the untrusted domain, thus asking for a confirmation when access to any resource is required.

To Sign or Not to Sign

When you design your application, you have a choice to sign it or not to sign it. Usually the best choice is not to sign the application at all. This way, the application runs in a sandbox and cannot execute any potentially dangerous code. The application is safe for the user to run, and fewer security alerts are shown. If the application attempts to execute dangerous code, the JRE throws a security exception. Note that new features introduced in Java SE (such as cross-domain access) and in Java FX (discussed later), enable you to develop more powerful untrusted applications without compromising the security of the user's system.

Another option for you as a developer is to sign your application with a valid certificate, but signing an application should be done only when absolutely necessary (for example, when you create a money transfer application). For more information, see the JAR Signing and Verification Tool. If you use NetBeans IDE for your JavaFX projects, you can create self-signed Web Start applications that are good for testing purposes. When you deploy your application, you should use a real (not self-signed) certificate.

On mobile devices, for a simple UI-only application that uses only the Java FX APIs, you do not have any reason to sign. If your JavaFX application is using APIs from JavaME technology, signing the application can improve the usability by reducing the number of prompts. Note that the use of any restricted API (including the use of networking) on a mobile device will produce confirmation prompts. For more information about mobile devices security, refer to the MIDP Application Security document.

JavaFX New Security Features

Persistence API

One of the most important features added to the JavaFX 1.2 release is the Persistence API. This feature enables you to create applications that can store a limited amount of data on the disk for later use. A good example of persistence usage in JavaFX is a game application that has an option to save user data.

Persistence in JavaFX is implemented with the help of two classes:

Storage Class. This class provides methods for storing data locally on the client system, even for applications that are running in an untrusted execution environment.
Resource Class. This class represents a stored entity on the platform, thus helping in identifying the source and making it usable.

For an example of Persistence API use, see the StickyNote JavaFX sample application.

Note: Using the Persistence API in an unsigned application on a mobile device generally causes user confirmation prompts.

Full-Screen Mode

Full-screen support is another useful feature added to the JavaFX 1.2 release. Full-screen mode can be entered by setting the fullScreen attribute of the Stage class to true. This is a good feature for a game application that deserves to be run in full-screen mode, where the player should be totally immersed in the game, with neither task bar nor desktop screen visible. Because of security considerations, the JavaFX 1.2 application has some restrictions on keyboard interaction for unsigned applets and applications (see Stage documentation for details). In addition, full-screen mode for unsigned applets and applications is supported only by at least Java 6 update 10. Take a look at the Full-Screen Sketching JavaFX sample, which can switch to full-screen mode.