John Stalker wrote:
> Hi there,
> Does anyone know if the aforementioned jar is pushed out to server
> instances created by node agents if it is deployed in a DAS? I
> imagine it could happen if the server instances are in a cluster, but
> what about stand alone instances? Does one have to go around to these
> installations after they are created to sign that jar?
Short answer, no (the JAR is not actually pushed out) and no (you don't
need to do anything).
Long answer: GlassFish does this for you but not by pushing out the
signed JAR. The GlassFish distribution includes an unsigned version of
appserv-jwsacc.jar in the ${install-dir}/lib directory. This includes
the DAS as well as any remote instances for which you install the
GlassFish bits. In response to a request to any instance to launch an
app client using Java Web Start, GlassFish will look for the signed
version of that JAR in a known location
(${domain-dir}/java-web-start/). It will not be there for the very
first launch after a new GlassFish installation, so GlassFish will
automatically create it, signing it with the default cert from the
keystore. This happens on any instance asked to launch an app client
via Java Web Start.
> Sort of related, should all the other jars participating in the
> web-start distributed app-client (ie my jars and 3rd party ones) be
> signed before being packaged and deployed?
That deserves a two-part answer:
In GlassFish v2 that's not necessary although you can do so if you
wish. In v2 GlassFish distributes the app client and the library JARs
in a single, generated app client JAR file. GlassFish signs that JAR,
by default using the default cert from the keystore. If you don't want
end-users to be prompted to trust that cert you can yourself sign the
generated app client JAR after you deploy the app containing the client,
using your own cert that either has a trusted certificate authority or
is one that your users will be comfortable trusting. The same is true,
by the way, for the signed appserv-jwsacc.jar file - you can create a
signed copy using your own cert in the directory I mentioned before. If
you do this after you install GlassFish on that system but before that
system is asked to respond to a Java Web Start launch request, GlassFish
will find and use the copy you created when it looks for the signed file.
GlassFish v3 (once app client support becomes available after the "v3
prelude" release) might work differently. For a number of reasons we
are looking at identifying each JAR file individually in the generated
JNLP document that describes the client and the JARs it needs.
(Remember v2 uses a single generated app client JAR which contains the
actual app client JAR and any library JARs.) If we do that then
GlassFish might *not* sign all those individual JARs itself, or perhaps
it would sign automatically only the JARs that are not already signed.
That way the Java Web Start security model could be in force on each of
the JARs separately which is much closer to the normal Java Web Start
approach. Because Java Web Start prompts the user about whether to
trust each different cert used to sign JARs (that is, unless the cert
has a trusted CA chain) in that case you might want to sign the JARs
yourself, using your own cert.
Sorry for the long answer but I thought it was worth highlighting how
this might be changing for v3.
- Tim
>
> Thanks!
> John
>
> Reference:
> http://java.sun.com/developer/technicalArticles/J2EE/jws-glassfish/part4.html#1
> http://blogs.sun.com/quinn/resource/signedJarsUserWriteup.html