Java Web Start Security

Java Web Start Security

Java Web Start (JWS) is a full-fledged Java application that allows Java client applications to be deployed, launched, and updated from a Web server. It provides a mechanism for application distribution through a Web server and facilitates Java rich-client access to applications over a network. The underlying technology of JWS is the Java Network Launch protocol (JNLP), which provides a standard way for packaging and provisioning the Java programs (as JAR files) and then launching Java programs over a network. The JNLP-packaged applications are typically started from a Web browser that launches the client-side JWS software, which downloads, caches, and then executes the application locally. Once the application is downloaded, it does not need to be downloaded again unless newer updates are made available in the server. These updates are done automatically in an incremental fashion during the client application startup. Applications launched using JWS are typically cached on the user 's machine and can also be run offline. Since the release of J2SE 1.4, JWS has been an integral part of the J2SE bundle, and it does not require a separate download [JWS].

JWS Security Model

Typical to a stand-alone Java application, JWS applications run outside a Web browser using the sandbox features of the underlying Java platform. JWS also allows defining security attributes for client-side Java applications and their access to local resources, such as file system access, making network connections, and so on. These security attributes are specified using XML tags in the JNLP descriptor file. The JNLP descriptor defines the application access privileges to the local and network resources. In addition, JWS allows the use of digital signatures for signing JAR files in order to verify the application origin and its integrity so that it can be trusted before it is downloaded to a client machine. The certificate used to sign the JAR files is verified using the trusted certificates in the client keystore. This helps users avoid starting malicious applications and inadvertent downloads without knowing the originating source of the application.

When downloading signed JARs, JWS displays a dialog box that mentions the source of the application and the signer's information before the application is executed. This allows users to make decisions regarding whether to grant additional privileges to the application or not. When downloading unsigned applications (unsigned JARs) that require access to local resources, JWS throws a "Security Advisory" dialog box notifying the user that an application requires access to the local resources and prompts the user with a question "Do you want to allow this action?" JWS will allow the user to grant the client application access to the local resources by clicking the "Yes" button in the Security Advisory dialog box.

Signing a JWS application is quite similar to the steps involved in signing an applet, as we saw in the previous section. To sign a JWS application for production, you must obtain a certificate from a certificate authority such as VeriSign and Thawte. For testing purposes, you may choose to use the key management tools provided with the J2SE bundle.

JNLP Settings for Security

To deploy a JWS application, in addition to JAR files, adding a .jnlp file is required. The JNLP file is an XML-based document that describes the application classes (JAR files), their location in a Web server, JRE version, and how to launch in the client environment. The client user downloads the JNLP file from the server, which automatically launches the JWS application on the client side. The JNLP file uses XML elements to describe a JWS application. The root element is tagged as <jnlp> , which contains the four core sub-elements: information , security , resources , and application-desc .

To enforce security, the <security> element is used to specify the required permissions. The security element provides two permission options: <all-permissions/> to provide an application with full access to the client's local computing resources, and <j2ee- application-client -permissions/> to provide a selected set of permissions that includes socket permissions, clipboard access permission, printing permission, and so forth. Example 3-19 is a JNLP file that shows putting all the elements including a <security> element setting with all permissions.

Example 3-19. JNLP file showing <security> elements

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="file:///c:/testarea/jnlp/">
  <information>
<title>My Signed Jar</title>
<vendor>Core Security Patterns</vendor>
  <homepage href="http://www.sec-patterns.com/signed" />
<description>Java Web start example</description>
</information>
<offline-allowed/>
<security>
  <all-permission/>
</security>
<resources>
  <j2se version="1.2+" />
  <jar href="SignedClientApp.jar"/>
</resources>
<application-desc main-class="SignedClientApp" />
</jnlp>