0

We are currently experiencing some problems with a network setup we have not used so far and I hope to get some more input how to work around this.

The network of a customer of us uses 4 JBoss instances on different servers all running the same version of our software. They share a common database and are running as needed. The software is working and ready to use. We don't replicate the sessions - every JBoss manages its own session pool.

The 4 JBoss instances are split in 2 different segments with 2 JBoss each. Each of these segments is routed using 2 different Apache web servers using mod_jk for simple load balancing. The connector used is AJP between the JBoss and the Apache servers.

Both Apache web servers are connected to a hardware load balancer / router (our customer is not very clear at this point) that routes internal requests (intranet) to one and external requests (internet) to the other web server. So we have one segment for internal and the other for external users.

The clients use an SSL encrypted HTTPs connection via their browsers - it's a web application. The SSL encryption is terminated by the hardware load balancer. The channel between the hardware load balancer and the 2 web servers is HTTP (no SSL anymore).

The problem:

At the end of the line the JBoss doesn't know of any SSL / HTTPs communication and therefor renders some 302 redirects with full http:// addresses instead of the https://. The client browser on the other end therefor switches from https:// - which it uses initially to connect to the web app - to http:// in the case of a 302 redirect from the JBoss.

Our solution:

We have offered two solutions. One is a simple rewrite rule on the last end - the hardware load balancer - that rewrites all http:// traffic to https://. This would work and keep the client connected but it is rejected by our customer because its unusual and no solution to the initial problem.

Another solution would be to extend the SSL encryption up to the web servers which would than be able to forward the secure flag signaling SSL communication the the JBoss via AJP and the JBoss would pick this up and redirect properly. This solution is rejected because of internal security concerns and guidelines.

What else?

So we are currently stuck and the fronts harden. Are there any alternatives to our 2 solutions?

  • Out of interest what are the security concerns/guidelines with pushing ssl to the webservers? – Decado Mar 23 '11 at 09:08
  • That's an internal regulation we can't get our hands on... part of the customer. I think they use it as an excuse... the real problem might be something else. We could just need another alternative to offer. – Daniel Bleisteiner Mar 23 '11 at 13:12

3 Answers3

1

Assuming they need to cope with both http & https traffic, you can try additionally to suggest one of the following:-

1) They could add a specific header to the requests from the loadbalancer that come over https so that the jboss instance knows it was originally an https request.

2) You could suggest that the https requests get sent to a different port in apache (say for example 8080 or even 443, but unencrypted) so that apache knows that they are from https.

Decado
  • 1,949
  • 11
  • 17
  • We only want to handle HTTPs... do you know which header value must be present at the mod-jk web server to trigger SSL knowledge of the JBoss? – Daniel Bleisteiner Mar 23 '11 at 16:12
1

Another option should be to use mod_headers in Apache to modify the Location response header:

Header edit Location ^http:(.*)$ https:$1
micah
  • 974
  • 6
  • 11
  • That's similar to mod_rewrite - right? I'll throw it in... thanks. – Daniel Bleisteiner Mar 23 '11 at 20:52
  • 1
    A little similar, but mod_rewrite really only allows you to alter URL requests. Using mod_headers you can alter any of the HTTP headers in either the request or the response. The option above looks for the HTTP header "Location" in the response from JBoss, and if it begins with http: it substitutes https. So the client web browser should always get a redirect to an https url. Hope that clarifies. – micah Mar 24 '11 at 03:47
1

We've had the same probem. The solution was to set the "scheme" and "secure" attribute on the AJP connector in JBoss/Tomcat. Set scheme to https and secure to true so the web containers knows which protocol is used at the front. If you use both http and https setup an second connector for https and connect by using an Apache vhost and different ajp settings. Maybe you also have to set the proxyName Attribute.

Michael
  • 11
  • 1