 | |
Articles Index
This part of the article discusses advanced topics and provides a look ahead at planned improvements to the Java Web Start feature of the GlassFish app server.
Any time users download executable code over the network they should be very cautious in allowing that code to run on their systems. The Java runtime, Java Web Start technology, and the GlassFish support for Java Web Start launches of application clients all take security very seriously and allow users to be as trusting or skeptical of application clients as they wish. This section summarizes a few of the key points about security in Java Web Start software and the GlassFish feature supporting it. The Java Web Start Security Sandbox Java Web Start technology enforces a security sandbox much like the sandbox for applets. The Java Web Start security rules do not permit applications to affect the user's local system unless the user allows it. An application launched using Java Web Start technology can affect the user's system in two ways. In the first, the code needing elevated access can reside in a signed JAR and the user accepts the certificate (more on this next.) Java Web Start technology allows parts of an application to be signed while other parts are not, depending on whether the code comes from a trusted, signed JAR or an unsigned JAR. After the user accepts the certificates used to sign the downloaded code, the Java Web Start sandbox allows the signed code to affect the user's system. The second way Java Web Start technology allows the application to affect the user's system is through the Java Web Start API. Unsigned application code can use this API to do things like read or write files or print documents, but Java Web Start software intercepts the request and prompts the user whether to allow the operation or to select a file for input or output. The GlassFish software itself does not use this API, but your client can. Digital Certificates and Signed JARs On a very simplified level, a digital certificate is a claim of identity. I can create my own certificate, called a self-signed certificate, that essentially asserts the following: I claim to be Tim Quinn and I stand behind this claim. To the general public, at least, this is probably not very convincing. Much more convincing would be the following: I claim to be Tim Quinn and VeriSign stands behind this claim. At least you are likely to be more convinced if you know and trust VeriSign. VeriSign, Thawte, and others are certificate authorities (CAs). These companies will, for a fee, give an applicant a digital certificate that they stand behind if the applicant establishes his, her, or its identity to the CA's satisfaction. Someone who accepts such a certificate accepts the thoroughness of the CA's process for confirming applicants' identities as well as the certificate holder's identity. When I have a certificate, self-signed or otherwise, I can use it in a variety of ways. One way is to sign digital content, such as a JAR file. If you agree to run code in a JAR file that I signed with my certificate, you accept both the explicit claim of identity (that the JAR came from me) and the implicit claim of trustworthiness (that the code inside will not harm your system). Identity and trust are different things. There might be people or companies or code providers whom you know very well but do not trust. We have already seen that Java Web Start software grants elevated permissions only to code from signed JARs and only if the end user accepts the certificates used to sign the JARs. Identity and trust appear again in this context. Auto-signed and Manually Signed JARs
Some of the GlassFish ACC code needs elevated permissions. In addition, some of the code triggered by your client
code – such as code to communicate with an EJB on the back-end server – also needs elevated
permissions. This is true whether you launch using the
The GlassFish app server automatically signs the
Your end users might not trust the self-signed GlassFish certificate. You can provide signed copies of these
files yourself, using your own certificate, in which case the GlassFish server serves those files instead.
You can sign the
The next few sections briefly explore a few additional subjects worth considering as you prepare to move to Java Web Start technology for launching application clients. Passing Information at Runtime Any new application clients you build that you intend to launch using Java Web Start technology should probably use classic graphical UIs or the Java Web Start API to gather whatever information they need, mainly because Java Web Start software works better with GUI applications than with command-line applications. But you can launch any application client using Java Web Start technology, including new or existing ones that might rely on command-line arguments or system properties. You pass these settings using the query string of the URL that launches the application client using the general form
To pass command-line arguments, include
in the runtime-settings where each "word" is what you would normally type as a word on the command line. Returning to the earlier example of the drawing tool, you would request the initial circle shape using
in the query string. Pass system property settings similarly, using
as part of runtime-settings, which has the same effect as this classic Java command-line fragment:
You can intermix argument settings and property settings. Properties can be in any order. Arguments are passed to your application client in the order in which they appear in the query string. For example, here is a URL for launching the drawing tool:
System.out, System.err, and System.in
If your existing application client writes to To change these settings:
Any Java Web Start application — including application clients — that you launch on this system writes all error and output messages to a trace file, or opens a console window to display such messages on the screen. You can find the trace files in one of these locations, depending on your operating system:
or
Application clients that read input from Handling Libraries (Assume Nothing!) If you have distributed classically launched application clients manually, you might have also installed library JARs on your end users' systems to support those application clients. As you plan to use Java Web Start technology to launch application clients, the only assumption you should make is that there is a Java runtime on end users' systems. This is because Java Web Start software – and therefore the GlassFish support for it – looks only in the JNLP document that launches the application client to establish the environment for the application client. If your application client needs library JARs, then include their classes in the application client JAR, or package the JARs in the containing EAR if the application client is embedded in one.
The engineering team for the GlassFish project wanted the initial implementation of Java Web Start support in the GlassFish server to let developers and administrators use this technology very easily without requiring any extra steps or work. As a member of that team, I also hoped that members of the GlassFish community would let us know what they liked about it and what they wanted added or changed. The team has been very pleased with the feedback so far. We had some ideas of our own about where to take this feature in the future. Many of those ideas have been confirmed by what our users said about their experiences with the feature. While we cannot commit to specific enhancements or changes, here are just two of the improvements that we hope to include in a future release. Smaller Footprint
Running application clients simply requires more and larger JAR files
than we or our users would like, for either We also want to look into exploiting the improvements in Java Web Start technology's handling in Java Platform, Standard Edition (Java SE) 6 of JAR indexing to defer or eliminate downloading JARs that are not needed for a particular application client launch. Better Customization of Generated JNLP Documents An earlier section of this article described how you as a developer can customize a few aspects of the generated JNLP document for an application client. We have received several requests for specific customizations of the JNLP, such as being able to identify a JAR as a native library (something Java Web Start technology already supports) or specifying custom icons or splash images. We have addressed this second request in a limited way in GlassFish V2. The GlassFish app server needs to control some key elements of the JNLP document. But ideally we would like to let developers specify much of the rest of the JNLP for an application client, while the GlassFish app server provides defaults for information that the developer omits. There are some interesting challenges in providing capability, but it is something we hope to achieve. Ultimately, what we hope most for the feature is that it fosters even broader usage of application clients, launched using Java Web Start technology, to provide richer and richer experiences for end users of enterprise applications. References
|
| |||||||||||||||||||||||||||
| |
| ||||||||||||
Print-friendly Version
