SSL termination using Hardware Load Balancer

[Former Member]

We are trying to implement SSL at the Hardware LoadBalancer layer and terminate the SSL there. Architecture includes Apache Reverse Proxy and Portal server running EP7 SP18. In this scenario we want encruption between the client browser and the Load Balancer (BigIP F5). The Load blancer will then decrypt the request and send it to the Apache reverse proxy on port 80. Apache Reverse proxy will send request to Portal J2EE engine on the http port.

this scenario seems to work in most cases but we are having issues with the standard portal login page. The login page is sent to the browser on https but when entering credentials and selecting the login button a request gets generated on port 80, not 443 (https) and is not serviced by the load balancer. 99% of the requests that get generated from the client borwser stay on port 443 as expected but for some reason this particular request switches to port 80.

How can we keep all requests generated on port 443 (https)?

[Former Member]

That is correct - certain requests being generated for port 80 and switching the protocol back to http causing the security warning. keeping the request on port 443 is the solution we're looking for just unsure how to accomplish that....

[Former Member]

Hello Brian (all)

I am facing the same issue - except we do not have the Apache proxy in the setup..... just HTTPS to a Cisco ACE load balancer and then HTTP to the portal.

Nearly all of the portal content is working great, but am facing the situation that some ESS content is switching to HTTP. In discussing with the network team, they have done the following:

1/ Replies from the portal server back to the client have an SSL rewrite performed, which modifies a 301 or 302 reply and changes http ULRs to https.

2/ The load balancer adds an HTTP header u201CClientProtocol httpsu201D to the request it sends to the portal server.

They feel we need to find a way to have the portal server only send either references with no host:header (i.e. http) or only send host:header with https to keep it all SSL.

Any advice?

Edited by: Eric Poellinger on Jan 5, 2011 5:09 AM

[Former Member]

Hi,

I think you should try to configure your load balancer to do the same job as a SAP Web Dispatcher : set the following header fields :

clientprotocol = https

x-sap-webdisp-ap = https=443 (for example)

Then the SAP system should be able to generate the load balancer enabled URLs.

PS : I have not tried this because I use a SAP Web Dispatcher...

Regards,

Olivier

[Former Member]

Brian's question (and Eric's follow-up question) are answered in this [other thread|;.

Regards,

Sean

[hofmann]

Hi,

if I understand your configuration correctly, all requests from the Apache are sent as HTTP to the portal. Therefore, when the user clicks on submit in the logon servlet, this request gets transformed from HTTPS to HTTP. The portal will send the response in the same protocoll used to generate the request. In your case: HTTP.

You'll have to implement a rule that will either

- change the HTTP answer from the load balancer to HTTPS or

- enforce that the request from /logon/logonServlet stays in HTTPS and doesn't get transformed to HTTP.

br,

Tobias

[Former Member]

Thanks for the response....

You are correct - load balancer terminates ssl connection and sends the request va http to apache reverse proxy which in turns sends request to portal on http port....

any insights into how the rule would be implemented to either end the request back to the browser via https would be appreciated. Would this be code running in portal or config either in apache or portal?

[Former Member]

as a work around for now we have implmented a rule at the load balancer layer to redirect any incoming request on http to https... This is not an elegant solution though as security warnings from the browser appear....

[hofmann]

Hi,

switching from HTTP to HTTPS shouldn't give you a security warning, but switching from HTTPS to HTTP should give you one.

To prevent security warning, you have at least 2 alternatives:

1. ensure that every communication from the Browser to the load balancer is always using the same protocol.

2. Switching the protocol without involving the client isn't really nice ... you can create an HTML file in the portal that will rewrite the protocol. In this case, the switch will get triggered by the browser and the user won't get a security message.

br,

Tobias