5 Replies Latest reply on May 10, 2007 3:15 AM by rino_salvade

    https with path and ejb3 can not be configured

    rino_salvade

      We're running an EJB3 application within JBoss4.0.5 GA. Since EJB3 uses Remoting as a basis I place this question here
      We would like to make this application accessible from the outside through a reverse proxy, that allows only https to be passed. The best thing would be to have both services (jndi and ejb3) sitting behind the same url path, so that the client could use something like this:
      https://myserver:8443/myapplication/jnid
      https://myserver:8443/myapplication/ejb

      It was no problem to make the jndi part accessible like this, there is plenty of documentation and samples.

      However I'm stuck with the ejb part

      My first approach was to go for the sslservlet as described in the Remoting documentation. I realized then that JBoss 4.0.5 comes with JBoss Remoting 1.4.3 which does not support the sslservlet.
      So I changed the libraries and stumbled then over the issue of JBES-1141, EJBProxy does not call Client.connect. I tried to fix that in the source code for a short while but ended with a null pointer exception in HTTPSClientInvoker.createSocketFactory

      So I went back to JBoss Remoting 1.4.3 to use the https approach. The idea was to have somthing like

      https://myserver:port1/myapplication/jndi
      https://myserver:port2/myapplication/ejb

      Not perfect but close.

      I was able to get the https version running ut only without the path, i.e. https://myserver:port2

      Then I tried the approach with the InvokerLocator to get the path in. To my understanding to make it work I have to set different parameters in the url for the initialitzazion (SSLImplementation, serverSocketFactory).
      Unfortunately the value for the serverSocketFactory contains a ":" since it is a mbean name. This seems to disturb the parsing of the url (yes, I added CDATA). To my understanding this is because the parser code looks for the last occurence of ":".
      I patched the 1.4.3 version to solve that (strangely enough the version from CVS contains less files than the one distributed with JBoss4.0.5GA)

      This results now in an exception in an excetion in the org.jboss.remoting.transport.coyote.ssl.RemotingServerSocketFactory.init saying that the mbean server is null.

      My last try to go with the invoker attribute failed because it is not possible to add a path to the serverBindAddress parameter.

      Any help to get the path in is very much appreciated.

      Sorry for the long and maybe a little confuse description, but it was a long night ;-)

        • 1. Re: https with path and ejb3 can not be configured
          rino_salvade

          I did some more investigation in the meantime.

          The exception with the JBoss Remoting 2.2.0 version was caused by the fact that it tried to access a trust store that was not existing. Through the parameter org.jboss.remoting.serverAuthMode one should be able to set from the outside that server certs are not validated. However I could so far not achieve that, neither through -D... nor through the config. So I changed the library code.
          It is working now, even so I'm not sure that my changes for the issue 1141 are absolutely correct.

          • 2. Re: https with path and ejb3 can not be configured
            rino_salvade

            It should be possible (according to the documentation) to pass in the client cofiguration through a URL parameter. However this results in an exception when starting up the server

            Caused by: java.io.IOException: Error initializing server socket factory SSL context: Can not find keystore url.
             at org.jboss.remoting.security.SSLSocketBuilder.initializeServerSocketFactorySSLContext(SSLSocketBuilder.java:1262)
             at org.jboss.remoting.security.SSLSocketBuilder.createCustomServerSocketFactory(SSLSocketBuilder.java:366)
             at org.jboss.remoting.security.SSLSocketBuilder.createSSLServerSocketFactory(SSLSocketBuilder.java:346)
             at org.jboss.remoting.security.SSLSocketBuilder.createSSLServerSocketFactory(SSLSocketBuilder.java:325)
             at org.jboss.remoting.ServerInvoker.createServerSocketFactory(ServerInvoker.java:513)
             ... 98 more


            Trying to do the same with the invoker approach , i.e like false causes the same exception

            • 3. Re: https with path and ejb3 can not be configured
              ron_sigal

              Hi Rino

              Are you still having problems with this issue? If so, I can tell you a couple of things that might help.

              1. The problem in JBWS-1141 comes from the fact that Remoting versions 2.x require a call to org.jboss.remoting.Client.connect() before any calls to Client.invoke(), whereas earlier versions of Remoting didn't impose that requirement. The current version of EJB3 is compatible with Remoting 2.x. Perhaps you can upgrade to JBossAS 4.2, where this problem is solved.

              2. Are you familiar with the "path" configuration attribute, which adds a path the the InvokerLocator:

               <attribute name="Configuration">
               <config>
               <invoker transport="socket">
               <attribute name="serverBindAddress">test.somedomain.com</attribute>
               <attribute name="serverBindPort">8084</attribute>
               <attribute name="path">foo/bar</attribute>
               </invoker>
               ...
              


              3. How are you passing in the org.jboss.remoting.serverAuthMode parameter? You want it to be available to the client when it is creating its socket factory. You could do that by passing it in the configuration map to the client, e.g., new Client(locator, configuration). If you put it in an XML server configuration file, be sure to use the "isParam" attribute.

              4.


              It should be possible (according to the documentation) to pass in the client cofiguration through a URL parameter. However this results in an exception when starting up the server


              What does your URL look like?

              -Ron

              • 4. Re: https with path and ejb3 can not be configured
                rino_salvade

                Hi Ron
                Thank you for your response

                1. The problem in JBWS-1141 comes from the fact that Remoting versions 2.x require a call to org.jboss.remoting.Client.connect() before any calls to Client.invoke(), whereas earlier versions of Remoting didn't impose that requirement. The current version of EJB3 is compatible with Remoting 2.x. Perhaps you can upgrade to JBossAS 4.2, where this problem is solved.

                This problem is solved. As I mentioned, I adapted the Remoting 2.x version so that it is backwards compatible with the 1.4.3 version. Unfortunately we're not currently upgrade our productive system to 4.2


                2. Are you familiar with the "path" configuration attribute, which adds a path the the InvokerLocator:

                I did find this parameter for the servlet approach, but I didn't know (and found nothing in the documentation) that it works as well for http


                3. How are you passing in the org.jboss.remoting.serverAuthMode parameter? You want it to be available to the client when it is creating its socket factory. You could do that by passing it in the configuration map to the client, e.g., new Client(locator, configuration). If you put it in an XML server configuration file, be sure to use the "isParam" attribute.

                What I tried was like this
                <mbean code="org.jboss.remoting.transport.Connector"
                 name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
                 <depends>jboss.aop:service=AspectDeployer</depends>
                 <attribute name="Configuration">
                 <config>
                 <invoker transport="sslservlet">
                 <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
                 <attribute name="serverBindPort">8443</attribute>
                 <attribute name="path">/invoker/EJBInvokerServlet</attribute>
                 <attribute name="org.jboss.remoting.serverAuthMode" isParam="true">false</attribute>
                 </invoker>
                 <handlers>
                 <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
                 </handlers>
                 </config>
                 </attribute>
                 </mbean>

                But as I wrote, I got the impression that the parameter is not used correctly


                What does your URL look like?

                The url looked like this
                <attribute name="InvokerLocator">servlet://${jboss.bind.address}:8443/invoker/EJBInvokerServlet?serverAuthMode=false</attribute>
                


                So, all the above mentioned problems are solved so far. It works fine with the sslservlet.
                The problem which I have currently is to make it accessible through a remote proxy (Web Entry Server) that requires client authentication. Geting the JNDIFactory and the JMXInvokerServlet works fine, but calling the EJB causes a problem. This is based on the fact that the calling opens up a new http session which is of course not yet authenticated. So when the http POST for the invocation is sent, the remote proxy answers with a redirect to get the client certificate. Unfortunately the redirect results that the http POST is transformed into a http GET (this is according to the http standards). The server side of the EJBInvokerServlet then can not handle the GET properly and goes into a npe.

                So any help on this would be appreciated. I was looking if it is possible to configure the request right from the beginning as a GET but wasn't lucky so far.

                Regards Rino

                • 5. Re: https with path and ejb3 can not be configured
                  rino_salvade

                  I solved the problem with the redirect in the meantime.
                  According to the RFC a redirect 302 should be answered with the same response as the original request, i.e. a POST with a POST. For historical reasons the standard JDK implementation of the JDK answers a POST with a GET.
                  There is a system property that handles this. Set

                  -Dhttp.strictPostRedirect=true
                  and a POST will be answered with a POST.
                  That did it :-)