6 Replies Latest reply on Nov 4, 2014 3:54 AM by Stian Lund

    Placing RHQ/JON behind load balancer (BigIP) and SSL

    Stian Lund Expert

      Hi,

      I brought this up with Thomas on the IRC earlier.

       

      We are trying to place RHQ (and JON) behind BigIP, since we often have developers asking for access, and just for convenience. At the moment we only have one RHQ per env, but might want to scale as well.

       

      The problem is:

      We are taking requests to https://rhq-server/coregui in the frontend, and backend points to port 7080 (non-ssl) on RHQ.

       

      We are not using 7443 against RHQ backend for various reasons, one is that it for some reason has client-auth enabled (don't know why...)

       

      When logging in, users going from BigIP get the error "The backend datasource is unavailable".

       

      The backend DS is however up and users can log in just by changing to http:// or simply reloading the page.

      So apparently session cookies are being set and the user logged in.

       

      Looking at the http traffic, users are actually getting a http 302 redirect to the address http://rhq-server/coregui.

      The 302 is the response to the POST to j_security_check.

       

      HTTP/1.1 302 Moved Temporarily

      Server: Apache-Coyote/1.1

      X-Powered-By: Servlet 2.4; JBoss-4.2.0.CR2 (build: SVNTag=JBoss_4_2_0_CR2 date=200704160918)/Tomcat-5.5

      Location: http://jon-server/

       

      So what is going on here?

       

      Can this behaviour be overridden some way? What it should do is send a redirect to the correct protocol being used.

      But maybe it does not know this, since on the backend it just receives a call to 7080.

       

      Stian

        • 1. Re: Placing RHQ/JON behind load balancer (BigIP) and SSL
          Elias Ross Master

          I did a little digging, not sure this is it:

           

          
           publicstaticvoid redirectTo(String path) {
                  if (path != null && !("/coregui/" + path).equals(com.google.gwt.user.client.Window.Location.getPath())) {
                      if (path.isEmpty()) {
                          isLoginView = false;
                      }
                      com.google.gwt.user.client.Window.Location.assign(GWT.getHostPageBaseURL() + path
                          + com.google.gwt.user.client.Window.Location.getQueryString()
                          + com.google.gwt.user.client.Window.Location.getHash());
                  }
              }
          
          

           

          It seems the redirection comes from what the GWT layer thinks it is. I'm guessing this could be fixed to not do that, but then again I don't really know the code.

           

          See also: http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/client/GWT.html#getModuleBaseURL()

          • 2. Re: Placing RHQ/JON behind load balancer (BigIP) and SSL
            Stian Lund Expert

            Thanks for the dig Elias

             

            I think the redirect from j_security_check should just redirect to /coregui and not prefix the protocol so it's left up to the client to set the protocol.

             

            And the error message from GWT is still wrong and the redirect actually doesn't redirect

             

             

            Stian

            • 3. Re: Placing RHQ/JON behind load balancer (BigIP) and SSL
              Thomas Segismont Expert

               

              I did a little digging, not sure this is it:

               

              1. publicstaticvoid redirectTo(String path) { 
              2.         if (path != null && !("/coregui/" + path).equals(com.google.gwt.user.client.Window.Location.getPath())) { 
              3.             if (path.isEmpty()) { 
              4.                 isLoginView = false; 
              5.             } 
              6.             com.google.gwt.user.client.Window.Location.assign(GWT.getHostPageBaseURL() + path 
              7.                 + com.google.gwt.user.client.Window.Location.getQueryString() 
              8.                 + com.google.gwt.user.client.Window.Location.getHash()); 
              9.         } 
              10.     } 

               

              It seems the redirection comes from what the GWT layer thinks it is. I'm guessing this could be fixed to not do that, but then again I don't really know the code.

               

              See also: http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/client/GWT.html#getModuleBaseURL()

               

               

              I don't think the problem is here. This GWT code runs in the browser in the end, and the browser has the right URL from the start.

              • 4. Re: Placing RHQ/JON behind load balancer (BigIP) and SSL
                Thomas Segismont Expert

                Stian Lund wrote:

                 

                Looking at the http traffic, users are actually getting a http 302 redirect to the address http://rhq-server/coregui.

                The 302 is the response to the POST to j_security_check.

                 

                HTTP/1.1 302 Moved Temporarily

                Server: Apache-Coyote/1.1

                X-Powered-By: Servlet 2.4; JBoss-4.2.0.CR2 (build: SVNTag=JBoss_4_2_0_CR2 date=200704160918)/Tomcat-5.5

                Location: http://jon-server/

                 

                I don't know much about Big IP, but I had to configure quite a few Apache based reverse proxies in the past. It looks like your BigIP configuration is missing an equivalent of the ProxyPassReverse directive.

                 

                See https://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassreverse

                1 of 1 people found this helpful
                • 5. Re: Placing RHQ/JON behind load balancer (BigIP) and SSL
                  Stian Lund Expert

                  I checked with our BigIP guys, and apparently they are able to write a rule like this:

                   

                    if { [TCP::local_port] equals "443" } {

                      # SSL connection

                      HTTP::header insert X-Forwarded-Proto https

                      }

                  This would also require me to enable a Remote IP valve in Tomcat, which kind of defeats the purpose of doing as little change as possible to the backend RHQ/JON.

                   

                  So if there is no other solution to avoid the redirect giving the http:// protocol in the Location header, I will have to just make the connection frontend SSL to backend SSL port 7443.

                   

                  Does anyone know by the way, why SSL client-auth is by default required in JON, while it in RHQ is off?

                   

                  For JON 3.1.2:

                  # Server-side SSL Security Configuration for HTTPS thru Tomcat

                  rhq.server.tomcat.security.client-auth-mode=want

                   

                  For RHQ 4.12:

                  rhq.server.tomcat.security.client-auth-mode=false

                  • 6. Re: Placing RHQ/JON behind load balancer (BigIP) and SSL
                    Stian Lund Expert

                    So does anyone know the background of why the SSL client-auth on inbound Tomcat was set to "want" in earlier versions and the reason why it was set to "false"?

                     

                    I think "false" is much less hassle so that's good, but I an curious as to why and when it was changed, and also if this will also be reflected in JON?