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.
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.
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.
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;
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.