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

[pathduck]

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

[genman]

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()

[pathduck]

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

[tsegismont]

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.

[tsegismont]

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

[pathduck]

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

[pathduck]

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?