[GLASSFISH-3900] Java Web Start app client cannot use SSL to communicate with the server Created: 06/Dec/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: standalone_client
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,900
Status Whiteboard:

as91ur1-na, as911-na


 Description   

(text below is copied from the GlassFish forum thread
http://forums.java.net/jive/thread.jspa?threadID=34030&tstart=0)

The automatic Web Start availability of enterprise application clients is very
convenient, but only if the client-server communication is encrypted (at least
in our environment). I pieced together what I think needs to happen to encrypt
client/server communication (add ior-security-config to sun-ejb-jar.xml; specify
IIOP/SSL port in target-server in sun-acc.xml, and possibly add a
client-credentials tag in sun-acc.xml; specify VMARGS for certs), however,
significant parts of the process require modifying sun-acc.xml.

I am unsure how to specify values in the (apparently) auto-generated sun-acc.xml
used by ACC apps deployed with Web Start. I initially tried modifying <domain
dir>/config, but to no avail. The sun-acc.xml distributed via Web Start (found
on my Windows machine in <user dir>/Local Settings/Temp) bears no resemblance to
the file I modified on the server.

Is there a way to control the sun-acc.xml for ACC applications deployed with Web
Start? Or is there another/better way of setting up IIOP/SSL communication?



 Comments   
Comment by Tim Quinn [ 06/Dec/07 ]

Although the Java Web Start feature does use up-to-date information about the
IIOP endpoints for the ORBs in the current host's cluster (if it participates in
one), there is no way to otherwise influence the sun-acc.xml information used
during a Java Web Start launch. The current implementation does not use the
existing $

{domain-dir}

/config/sun-acc.xml as a starting point.

Comment by harpreet [ 12/Mar/08 ]

approving for v2.1 - expect Web Start client to behave as ACC.

Comment by Tim Quinn [ 10/Oct/08 ]

We'd like to address this, at least partly, for V2.1, and I wanted to see to
what extent one possible solution would meet people's needs.

The server would look for $

{domain-dir}/sun-acc.jws.xml which would be a version
of sun-acc.xml tailored for Java Web Start client launches. If it finds none it
would use the existing ${domain-dir}

/sun-acc.xml. The app client container
would then use the contents of the selected file from the server during the Java
Web Start client launch.

This allows you to specify the secure port in the target-server element(s). It
also allows you to specify the target-element/security/ssl element to request
that the client use SSL even if the server does not request it. (My colleague
in the security team reports that the client should use SSL if the server
requires it, regardless of whether the sun-acc.xml specifies it.)

This would not resolve everything about secured communication between the client
and server. The sun-acc.xml file contains some information that truly depends
on the server (such as the target-server information) and also some that can be
client-specific (username, password, cert-nickname). If you leave the
sun-acc.xml username and password absent then the ACC prompts the user for
those, which seems reasonable.

One problem that would remain is the selection and use of a certificate nickname
(alias) if you have set up the server to require client authentication via cert.
The alias specified in the ssl element's cert-nickname attribute might not be
correct for all the users that will be using your applications, and there's also
the issue of access to a keystore and truststore on the client systems.

So for V2.1 there might not be a solution for the client cert part of the
problem. But we could address the other aspects I mentioned above.

Comment by harpreet [ 20/Oct/08 ]

removing from approved list as issue not critical to release.

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.

Generated at Mon Jul 25 22:28:13 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.