4 Replies Latest reply on Mar 27, 2006 3:29 PM by starksm64

    SSLSocketFactory impl

      JBWS-683 is going to require custom implementation of javax.net.ssl.SSLSocketFactory (well, at least a way to get a properly configured instance of SSLSocket anyhow). This is required because need to be able to configure SSL properties per instance (and jdk default impl only allows global config via sys property).

      The only code within JBossAS source tree that has anything like this (at least that I could find), is within the org.jboss.axis.components.net package, which we are replacing. So looks like best option now is to create an independant implementation. Since will be what I use within remoting, it can live within the remoting project. However, I would prefer this live in a common area, which remoting (and others can use).

      So, two questions now; 1) what requirements do people have beyond JBWS-683 and 2) where should this live?

        • 1. Re: SSLSocketFactory impl
          starksm64

          So these properties look to be essentially aliases for the standard jsse properties, plus a socket timeout notion. The main thing we have to address is externalizing all keystore, socket configuration information from the socket factory to allow for alternate ways to configure the socket factory instance.

          This has to be outside of the javax.net.SocketFactory api. There are related classes in the common module under the org.jboss.util.net package. That should be the core java bean based impl with Properties, and SecurityDomain based subclasses outside of this dealing with how to populate the common java bean based impl with the necessary components (keystore, truststore, socket options, ...)

          • 2. Re: SSLSocketFactory impl

            Have finished initial go at the implementation. Is checked into remoting project for now (http://viewcvs.labs.jboss.com/cgi-bin/viewcvs.cgi/JBossRemoting/src/main/org/jboss/remoting/util/socket/RemotingSSLSocketFactory.java)

            There are still a few more configuration hooks that could be added (like setting the ciphers to be used, etc.), but think these will be fairly easy to add now. The basics are all there though (store path, password, type, alorigthm, etc.). Guess for anything that is *not* there that should be, needs to be entered as a jira issue and assigned to me (otherwise will loose them).

            Now is the issue of where the permanent home for this should be. Originally I thought it should be in JBossAS common, but now think should be within remoting. The main reason is for versioning. Since remoting will need this class, will be an issue of getting a jboss-common.jar in released form to include in remoting. However, if lives in JBossAS 4.0 branch and HEAD, and they get out of sync, remoting will be hosed. Also, if put this into JBossAS 4.0 branch, and want to include in JBoss Remoting 1.4.1, how do I include a jboss-common.jar from JBossAS 4.0 branch and yet still use the JBoss Remoting 1.4.1 in JBossAS 4.0.4 (without first using a dev build of jboss-common.jar for remoting release)?

            • 3. Re: SSLSocketFactory impl
              anil.saldhana

              Makes perfect sense to have it in the remoting project, unless Scott thinks otherwise.

              • 4. Re: SSLSocketFactory impl
                starksm64

                the common module is in the process of being broken up so its not going to be part of the jbossas in the future. The RemotingSSLSocketFactory still needs some work to be general enough as its always loading the KeyStore, KeyManager, TrustManager, etc from the classpath/filesystem. These should be injectable resources. For now I would leave the RemotingSSLSocketFactory in remoting think about a common implementation once the common module is broken out.