How do I rewrite soap:address to always HTTPS
uromahn Jan 8, 2010 5:56 PMWe have a strange issue here and I must assume that someone else must have run into this before.
We are currently deploying our EJB3-based web service on JBossAS 5.1.0.GA.
The Session bean that implements our service methods is using annotations to generate all the necessary artifacts upon deployment, especially the WSDL.
As everybody knows, JBoss is generating the service URL in the <soap:address> field every time a WSDL gets re-generated.
We are also aware that there are certain options to configure how this URL gets generated in the deployers/jbossws.deployer/META-INF/jboss-beans.xml.
However, we have a configuration that just never gives us the correct protocol in the service URL.
We are using a F5 load balancer to front-end our traffic. All traffic up to the F5 is using HTTPS. Based on rules, the F5 is now forwarding the requests to a set of Apache HTTPD server - this traffic is using HTTP. The Apache HTTPD server are now configured to use mod_proxy_ajp to send the request to our individual JBoss server who will then ultimately serve this request.
So, we have multiple options to configure the generation of the service URL:
- we configure it statically by setting "webServiceHost" to our public server name, or
- we configure it using dynamic rewrite based on the request URL
If we use option #1, JBoss will always generate a service URL with "http" no matter what else we do and if we use option #2, JBoss will also always generate a URL with "http" since the request from the F5 to Apache is actually just HTTP. The only way to force a "https" address in option #1 is to configure our webservice with <transport-guarantee>CONFIDENTIAL</transport-guarantee> in jboss.xml (or in the @WebContext annotation). However, this does not work either because the incoming traffic is actually HTTP and JBossWS is expecting HTTPS so it correctly never responds.
So, our question now would be:
How can we configure JBossWS to generate a service URL with "https" regardless of whether the service actually expects encrypted requests or not?
I could not find any viable solutions at all yet, so any ideas may be helpful.