glassfish
  1. glassfish
  2. GLASSFISH-3900

Java Web Start app client cannot use SSL to communicate with the server

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: v2.1
    • Fix Version/s: not determined
    • Component/s: standalone_client
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      3,900
    • Status Whiteboard:
      Hide

      as91ur1-na, as911-na

      Show
      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?

        Activity

        Tim Quinn created issue -
        Hide
        Tim Quinn added a comment -

        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.

        Show
        Tim Quinn added a comment - 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.
        Hide
        harpreet added a comment -

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

        Show
        harpreet added a comment - approving for v2.1 - expect Web Start client to behave as ACC.
        Hide
        Tim Quinn added a comment -

        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.

        Show
        Tim Quinn added a comment - 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.
        Hide
        harpreet added a comment -

        removing from approved list as issue not critical to release.

        Show
        harpreet added a comment - removing from approved list as issue not critical to release.
        Hide
        sanandal added a comment -

        "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."

        Show
        sanandal added a comment - "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."
        Hide
        kumara added a comment -

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

        Show
        kumara added a comment - Changing version from 9.1.1 to v2.1 to reflect new name/version.
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 3900 35504
        Hide
        Tom Mueller added a comment -

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

        Show
        Tom Mueller added a comment - Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.
        Tom Mueller made changes -
        Fix Version/s not determined [ 11149 ]
        Fix Version/s 9.1.1 [ 10973 ]

          People

          • Assignee:
            Tim Quinn
            Reporter:
            Tim Quinn
          • Votes:
            3 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: