Problem Behavior
When logging in via an F5 Load Balancer, accessing a Workflow hangs, and the browser shows the following error (as per the Chrome developer console).
Mixed Content: The page at 'https://igl.rsa.com/aveksa/main?Oid=5751%3AWPDS&ReqType=GetPage&PageID=ChangeApprovalDefinitionPageData&ObjectClass=com.aveksa.gui.objects.workflow.GuiWorkflowProcessDefinition' was loaded over HTTPS, but requested an insecure stylesheet 'http://igl.rsa.com/aveksaWFArchitect/static/wp-architect/build/production/AppClientArchitect/classic/resources/wp-base/icons/style.css'. This request has been blocked; the content must be served over HTTPS
The server name in the HTTPS URL (that is, https://igl.rsa.com) will be different on your implementation of RSA Identity Governance and Lifecycle.
Expected Behavior
When logging in directly to RSA Identity Governance & Lifecycle via the web server or the application server, accessing a Workflow works as expected. So, in this scenario, the URL is not handled by the F5 Load Balancer.
Configuration
This issue relates to the following specific products:
- RSA Identity Governance & Lifecycle 7.0.2.
- IBM WebSphere application server version 8.x.
- F5 Load Balancer.
The issue does not apply to the JBoss/WildFly or Oracle WebLogic application server.
For these products to encounter the issue, they need to be in the following specific configuration:
- IBM WebSphere has been implemented in the Application Cluster configuration.
- An F5 Load Balancer has been implemented to redirect HTTP traffic.
Example Deployment
- F5 Load Balancer.
- Two IBM Web Servers (hardware).
- Two WebSphere Application Servers.
The cause of the issue is documented in the following IBM Support Technote and F5 (Load Balancer) Knowledge article;
where it states that "[y]ou must update the external component handling the SSL connection as well as the WebSphere Application Server configuration."
Please work through the solution steps from the IBM Support Technote
swg21221253 - Offloading SSL traffic causes improper redirects or links to HTTP.
For your convenience, the IBM solution has been reproduced here.
Resolving the problem
The behavior of the WebSphere Application Server has been modified to help avoid the symptoms mentioned in the problem description. To take advantage of such behavior, you must update the external component handling the SSL connection as well as the WebSphere Application Server configuration as follows:
- Update the SSL accelerator/proxy/load balancer to insert a custom HTTP header variable into HTTP requests that will be read by the WebSphere Application Server. The Related information below offers a couple of vendor-specific examples from F5 and Citrix.
- Add the property, "httpsIndicatorHeader", into the WebSphere_Portal web container properties as follows:
- Log into the WebSphere Administrative console.
- Navigate to Servers --> Application Servers --> WebSphere_Portal --> Web Container --> Custom Properties.
- Click "New". For the Name field, enter "httpsIndicatorHeader". The value field should contain the name of the HTTP header field* inserted by the SSL accelerator/proxy/load balancer. WebSphere Application Server does not look at the actual value of the header field on the incoming request.
- If in a cluster, repeat this step for each Portal server in the cluster.
- Save the changes and restart the server.
The name of the field that is added to the HTTP header is left to the discretion of the administrator of the external component handling SSL. WebSphere Application Server is simply going to look at this name in order to confirm that it matches the httpsIndicatorHeader value.
