Secure Proxy server (Access Gateway) with load balancer in front and after all HTTPS traffic

[Duc Tran]

The attached diagram should be able give a clear picture of an architecture that we are proposing which includes CA Secure Proxy server in the mix.  We are very new to the Secure Proxy server concept but due to our migration from Apache web servers to Nginx web servers, we will no longer be able to use the CA SiteMinder traditional web agents on the Nginx web servers and therefore, the Secure Proxy server is our only option (aside from paying CA a ridiculous amount for "global delivery product for Nginx web agent).

 

Our understanding is that the Secure Proxy server is designed to be able to have a load balancer in front and also another load balancer after the SPS, but how do we setup/configure SPS to first accept HTTPS traffic from a load balancer then then based on the proxy rules, forward the traffic to a backend load balancer over the same HTTPS channel?  Our F5 load balancer has the "SSL Passthrough" option so it simply pass the HTTPS requests to the pool members (web servers) to terminate the SSL session at the web server layer.

 

We setup our new Secure Proxy server environment as a proof of concept and tested out the proxy rules with simple web applications over HTTP without load balancers.  Our network security policy requires SSL encryption over ALL HTTP traffic.  Perhaps the question for us here is not necessarily with SPS, but with the SPS Apache web server, specifically how to get the SPS Apache web server to receive the HTTPS request from the first LB and based on the proxy rules, forward that HTTPS request to the backend LB.

 

Much thanks in advance for any help and suggestions folks could provide.

 

Duc Tran,

Attachment(s)

SPS with load balancers over HTTPS.pdf   185 KB 1 version

[Ujwol]

Hi Duc,

 

So ,based on your requirement what you are probalby looking for is following :

 

- How to enable SSL from your front end (F5 LB1) to SPS Apache Web server, &

- How to enable SSL from SPS HTTPClient noodle to backend (F5 LB2)

 

This has been documented here :

SSL Settings Configuration - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 

 

I am imagining you will also need to debug the SSL connectivity while you test these things out.

For which you can configure debug SSL logging for SPS as per this tech note :

https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.TEC1860387.html

[Jason_Wilcox]

To further what Ujwol stated,

 

You aren't passing the SSL connection on through to LB2, in this case you are terminating SSL on the Access Gateway (Formerly SPS) and then initiating a new SSL connection from the Access Gateway to LB2 which in turn is doing SSL passthrough to your backend web servers. 

 

The documentation Ujwol pointed you to should help you with the configurations if you are using the proxy UI, if you not you can also do it manually as documented here:

 

Configuring SSL for CA SiteMinder® SPS - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 

 

Let us know how its going

[Duc Tran]

Ujwol / Wilja32,

 

Thank you for your responses, much appreciated it.  Our enterprise security policy requires that we encrypt all HTTP traffic (SSL everywhere) so our typical setup for a web application looks like this:

 

1) Client web browser request: https://webapp.company.com:443 

2) F5 LB receives this request but will not terminate the SSL connection (SSL pass-through) and then distribute the request to destination web servers at: https://web1.company.com:8443 or https://web2.company.com:8443 

3) both web1 and web2 each has a copy of the server certificate for: webapp.company.com so it can terminate/negotiate the SSL handshake with the client.

 

As you can see, there is only one SSL certificate to encrypt the HTTP traffic at the web server.  Based on your response, it looks like below is what the flow would look like with SPS added into the picture:

 

1) Client web browser request: https://webapp.company.com:443

2) F5 LB1 receives request with SSL Pass-through, it then distribute to destination server: https://SPS1.company.com:8443 or https://SPS2.company.com:8443 

3) Both SPS1 and SPS2 has a copy of the server certificate for: webapp.company.com and so it does the SSL handshake initializing the SSL session with the client/browser.

4) SPS then distribute/forward traffic to the destination server: F5 LB2: - - - > https://lb2.webapp.company.com:8443 

5) F5 LB2 does not terminate SSL and pass the request to destination servers: https://web1.company.com:8443 or https://web2.company.com:8443 

6) web1 and web2 each has its own server certificate for LB2.webapp.company.com so it initiate SSL handshake with SPS.

 

Please let me know if this flow is the only way that we can implement SPS with SSL going to SPS and then SSL to destination servers.

 

Thanks in advance,

 

Duc Tran.

[Jason_Wilcox]

Yes that is the correct way to implement it. 

It is not the only way, you could via split DNS or host file entries on the SPS Servers continue to use webapp.company.com all the way back. I personally think it gets more confusing using that approach but it could be done. You could also have https://lb2.webapp.company.com listening on 443 so no port necessary, the F5 maps it to 8443 on the backend servers. Once again, a choice and minor variation on your explanation.

 

Jason

[Duc Tran]

Jason,

 

Much thanks for your response and for the good suggestions.  What we are also trying to avoid is to have the SPS terminate and initialize the SSL connection with the client web browser because we anticipate on deploying dozens of applications with different domains so each app will have it's own VeriSign certificate and we would prefer not to manage these certificates at the SPS but instead at either F5 or the web servers.

 

The only way that I can see this happening is to have the F5 LB1 terminate/initialized SSL connection with web browser (https://webap.company.com:443) and then do a SSL connection to SPS using a self-signed cert (https://sps1.company.com:8443 or https://sps2.company.com:8443) then SPS forward to F5 LB2 (https://lb2.company.com:8443), F5 LB2 does not terminate SSL so it forward to destination web servers with SSL pass-through to (https://web1.company.com:8443 or https://web2.company.com:8443), also with a self-signed cert.

 

I think this would avoid having SPS does the SSL termination with the client's web browser so we can leave it up to the first F5 LB to manage the VeriSign trusted SSL certificate (request/renew cert) and use the self-signed certs for the rest of the SSL connections, but this would mean we would have to do two additional encryption and decryption, one at SPS and another at the web servers total of encrypting and decrypting SSL three times.

 

Your thoughts?

 

Thanks,

 

Duc Tran.

[Jason_Wilcox]

Completely understand the desire. 

You can do it either way. If you terminate on the F5 it is one more certificate overall you have to deal with (F5 to SPS) than if you continue to have the external F5 do SSL Passthrough. From an SPS perspective, and more importantly from a user perspective there isn't a functional difference, its just a configuration difference. 

 

Jason

[Duc Tran]

Jason,

 

How much of a performance impact do you think it is with having total of three SSL encryption/decryption for a an HTTPS connection?  We would prefer managing the SSL certificate with our F5 LB is because it does a more effective way than how the SPS manages certificates.  The SPS documentation mentioned that each time you install/load a new SSL certificate or renew an existing certificate you will need to restart the SPS server.  This is not desirable if you have dozens of apps that relies on the SPS being up and available to serve the apps which in this case would be interrupted with a minor certificate administration task on SPS.

[Jason_Wilcox]

Correct, the updating of SSL certs will cause an interruption.

As for a performance impact, it will depend on load. Because each of the connections use pooling (F5 to SPS, SPS to webserver) as long as those connections are live and active, they will be done across the connection pool so you don't have to pay the renegotiation penalty for each request. Under light loads, when those pools have timed out, you can expect a small impact. 

[Duc Tran]

Jason,

 

Thank you so much for all of the responses.  Very much appreciated it.  I think we will need to pursue an alternative solution to the SPS product.  I hope CA customers out there would continue to bug CA about the Nginx webagent so they would eventually release it as a standard component of SiteMinder rather than a global delivery product.

 

Duc Tran.