Yet again, I have seen customers editing a web.xml file within BPM, changing <transport-guarantee> from CONFIDENTIAL to NONE.
The most common reason why customers want to do that is SSL offloading: SSL/TLS used to be considered expensive and thus there were attempts to avoid HTTPS for "internal" communication and offload all the crypto work to some SSL termination endpoint only.
End users cannot connect to the WebSphere Application Server (WAS) cluster member running BPM directly, they have to go through some network intermediaries, typically at least an instance of IBM HTTP Server, but reverse proxies or load balancers are seen regularly, too. Of course, traffic between end user browers and the data center needs to be encrypted using HTTPS. Almost all of these requests contain credentials of some type, either username and password during login or an LTPA token cookie which is good to impersonate the user for some time. However, once a request reached the data center, some customers consider their internal infrastructure as "secure enough" to allow non-secure HTTP communication between various servers inside the data center. I disagree, and so do industry standards and regulations that you might need to comply with: PCI-DSS, FISMA, HIPAA, ISO 27k and so on. Sending credentials in the clear is not a good idea.
Anyway, non-secure HTTP between some intermediary and the WAS web container can be achieved WITHOUT modifying the product shipped web.xml files. (Note that such modifications are generally unsupported and not only make the web container reachable over non-secure HTTP, it also omits the enforcement of secure connections from end users to the outermost node in your data center network unless otherwise configured.)
The key term to look for is httpsIndicatorHeader. See the WAS knowledge center
Going through the details using an open source load balancer as an example...
Disabling HTTPS in WAS
- In order to demonstrate that non-secure connections are possible, we disable the HTTPS in WAS
- Deleting the ports
- Removing the ports from virtual host "default_host":
- Validation: After restart, the web application can no longer be reached on https://<myhost>:9443/ProcessPortal
- Deleting the ports
Set up haproxy as SSL Offloader on a Linux box in front of BPM
I have a Linux VMWare configured with NAT networkting running on my laptop.
- Added its IP address in my laptop’s c:\windows\system32\drivers\etc\hosts file as myproxy.ibm.com:
- Accepts inbound https requests (http requests to port 80 are redirected to https 443)
- Forwards to http://192.168.65.1:8081 – a burp suite proxy on my laptop in order to record the HTTP traffic
- Injects an HTTP header into every request with header name “X-SSL-OFFLOAD” and value “haproxy”
Configuring the httpsIndicatorHeader in BPM
Using a web container customer property (set on every application server) we can tell WebSphere Application Server that the presence of a given HTTP header indicates that the original request (handled by some intermediary) was in fact a secure request of HTTPS even though the request arrived at WebSphere’s web container over insecure HTTP.
In this example, the expected header name must be X-SSL-OFFLOAD – the header that we inject in haproxy.
Clear browser cache and access https://myproxy.ibm.com/bpmrest-ui
The BPM REST API Tester application can be used fully functional. If you observe network traffic carefully, you can see traffic between browser and HAProxy on https and then HAProxy talking back to the WAS web container over non-secure HTTP. Even though this web application (in BPM 188.8.131.52) is configured with transport-guarantee CONFIDENTIAL so that secure connections are enforced, there is no redirect sent by the web container when HAProxy connects on a non-secure connection.
Internally, code running in the application server can invoke JEE APIs like request.isSecure() and it will believe the connection was secure (which it is from a browser perpective, too). WAS will then also be able to set cookies with the Secure flag if configured accordingly.
The sniffing proxy shows several insecure HTTP requests from haproxy to BPM including the injected header:
Most importantly, we can see that the initial request for the context root is redirected to a welcome page, which in turn redirects to another page and ultimately to the login page.
These redirects use https (as defined in the application), but do not modify the port. This is exactly what we need for SSL offloading: the end users access an intermediary using HTTPS. The intermediary tells WebSphere that the original request was HTTPS, so
- The request is processed even though it was received on an unencrypted connection
- There is no need to change the port when redirected to the next secure page
A full SSL offloading configuration for BPM also includes EndpointService configuration to ensure URLs are generated to point to the proxy server for EXTNERAL_CLIENT scenarions, see http://www-01.ibm.com/support/knowledgecenter/SSFPJS_8.5.6/com.ibm.wbpm.imuc.doc/topics/tconfig_custom_cluster_env.html