CA Secure Proxy Server - on premise or cloud

[Duc Tran]

Hello Folks,

 

We are seeking advice with our upcoming implementation of CA Secure Proxy server.  Currently we have a suite of web applications that are being protected by our CA SiteMinder r12.52 web agent/policy servers.  Our web applications are either internal or external web apps.  The "internal" apps are web applications that are accessible only from within our internal network and the SiteMinder authentication scheme is IWA.  The external apps are web applications that are accessible from outside of our network and uses form based auth or SAML.

 

We are moving our internal web apps to the AWS cloud, and will be using Nginx web servers rather than our standard Apache web server on the cloud as a web server frontend.  Currently CA SiteMinder does not have an out of the box web agent for Nginx so CA advised us to implement CA Secure Proxy server to protect the apps fronted by Nginx web servers on the AWS cloud.  The Secure Proxy Server will only be used to protect the applications hosted on AWS running on Nginx web servers.  Given that our SiteMinder policy server along with the user directory store and Active Directory being hosted on premise, would you folks see any potential conflict with installing the Secure Proxy Server on premise as well rather than on the same AWS cloud where the Nginx web apps are hosted?

 

Much thanks in advance.

 

Duc Tran

[Hongxu Liu]

Installing or integrate with SPS should not present any additional conflict. SPS serves its purpose as proxy.

The question is should you install SPS on premise or on cloud in term of performance, no one can know until you have done and tested it.

I also come across a CA Global Delivery Integration module for "CA Single Sign-On with NGiNX".

CA Global Delivery Packaged Work Product Download Index - CA Technologies 

It will require additional license from CA Global Delivery, could be worthwhile to check it out as well, so you may avoid SPS.

 

Hope this helps.

 

Hongxu

[Duc Tran]

Hi Hongxu,

 

Thank you for your response and feedback on this.  My other question relating to the Secure Proxy Server is the federation services component of SPS.  We have been using the Web Agent Option Pack as our federation services.  We currently have an extensive deployment of the federation services serving as both IDP and SP for many SAML service partners.  Would CA recommend customers to move away from the Web Agent Option Pack and use the SPS federation services if SPS is deployed?  If choosing to use the SPS federation services, will there be any kind of federation migration required from moving away from the Web Agent Option Pack to SPS federation services?

 

My assumption on this is that we would simply switch out the federation services host/base URL from current WAOP host of: - - > https://waop-host.company.com/affwebservices/ to the new SPS federation services: - - > https://sps-fed.company.com/affwebservices/

 

Thanks in advance!

[Hongxu Liu]

Hi Duc Tran,

 

SPS certainly will reduce the number of deployments you need.

However, SPS is not a replacement of Web Agent Option Pack, in fact, SPS just build-in with Web Agent Option Pack out of box. I am in no position to recommend move away from the Web Agent Option Pack, because that is a business decision, for extensive deployment of the federation services, best to consult with CA pre-sales or a CA business architect when they are on site. Even you choose to do that, I imagine it will be a slow and gradual process of doing it.

 

Thanks,

Hongxu

[Legacy User]

Question : If choosing to use the SPS federation services, will there be any kind of federation migration required from moving away from the Web Agent Option Pack to SPS federation services?

 

[HUBERT] No it is seamless. It is the same WAOP code packaged within CA Access Gateway. So no change in configurations on Policy Servers, unless as your thought process is to have a new FQDN for CA Access Gateway, this will have configuration changes on Federation objects defined in Policy Server and at your partners too.

 

 

Question : My assumption on this is that we would simply switch out the federation services host/base URL from current WAOP host of: - - > https://waop-host.company.com/affwebservices/ to the new SPS federation services: - - > https://sps-fed.company.com/affwebservices/

 

[HUBERT] Have you thought about bring in CA Access Gateway into the same FQDN of WAOP i.e. https://waop-host.company.com/affwebservices. That way your impact on partners would be none. I would slowly bring one by one CA Access Gateway into the mix and start taking the WAOP offline. This way the impact to partners is none and no change in configurations on Policy Server Federations Objects. The only thing I would take utmost care is versions of WAOP Vs CA Access Gateway Vs Policy Server. If all versions are in sync OR are conducive to facilitate running WA-WAOP and CA Access in parallel, with eventually taking WA-WAOP offline.

[Duc Tran]

Hubert... Thank You!

 

One final question. 

So we have a separate and dedicated Apache web server which has the SiteMinder r12.52 Apache web agent along with the Agent Option Pack to serve as a dedicated federation services server (fedsvc.company.com/affwebservices) and this is currently being used heavily in our production environment.  The only reason we are introducing the SPS to our infrastructure is because we are running Nginx web servers on our AWS cloud and need to protect these web apps but don't want to pay for CA global delivery to get the NginX custom web agent product. 

 

So given that our current WAOP is working fine as designed in our infrastructure for the federation services, but with the introduction of SPS, would you recommend us to utilize the WAOP deployed on SPS or to stick with our currently deployed WAOP? Is the only difference between our currently deployed WAOP and the SPS WAOP is New Atlanta ServletExec Java servlet V.S. the SPS Tomcat Java servlet?

 

Thanks again!

[Legacy User]

Here's what I'd do in your shoes....

 

Its not the technicalities, but the business aspect. So replacing something is not an easy task, no matter how lucrative the new shiny thing looks. We also have to look at resourcing / time / money. What I mean by that is, if we leave the existing WA-WAOP as is and let it do the federation tasks, then it is BAU for federation. We can purely focus on using CA Access Gateway for acting a reverse proxy for NGNIX WebServers. If we were to also include CA Access Gateway into the WA-WAOP mix, then our scope widens. This means more design, more testing etc. So my question really would be what is your immediate business needs and longer terms needs. Structure the change accordingly. For e.g. if your immediate business goal is only as Reverse Proxy for NGINX, then just use the CA AG for that. But in future you can create an additional virtual host and route federation traffic from fedsvc.company.com DNS to this new virtual host in CA AG. Again that would be a new project and effort.

 

 

As for your other question i.e. Is the only difference between our currently deployed WAOP and the SPS WAOP is New Atlanta ServletExec Java servlet V.S. the SPS Tomcat Java servlet? 

That is just one of the changes. There is a lot more under the covers. As you starting working on CA AG and get familiarized you'd understand.

 

 

These are my view points and what I'd do or suggest after looking at both sides of the coin i.e. Technical and Business.

[Duc Tran]

Hubert, I think you answered the only remaining question for us.  Thank You!

 

We are moving many of our web apps to our AWS cloud infrastructure which only runs Nginx as both web and Java apps and we were quite disappointed to learn that CA does not provide a native web agent for Nginx web servers.  CA pointed us toward Secure Proxy Server as a solution so we have been doing much reading on documentations for SPS in preparation to deploy the first DEV SPS server.

 

Up to now, I have been very comfortable with securing our web applications with the traditional web agents (IIS & Apache), but I am not feeling very comfortable with the concept of the Secure Proxy Server, but again this change can provide new capabilities and would probably eventually grow on us.  If you have the time to respond and provide us with your thoughts on the concept and long term prospect of CA Secure Proxy Server, we would very much be grateful for that.

 

Thanks Again Hubert.

 

Duc Tran