Symantec Access Management

Expand all | Collapse all

New to CA Access Gateway - r12.52 SP1 CR05

Jump to Best Answer
  • 1.  New to CA Access Gateway - r12.52 SP1 CR05

    Posted 02-15-2017 12:55 PM

    Hi Folks,


    So we have our CA Secure Proxy Server r12.52 SP1 installed and configured with our policy server but I can't seem to find documentations on how to actually start protecting a new or an existing web application with the Secure Proxy Server.  Example: We have an existing app:  which is currently protected by the traditional SiteMinder web agent architecture.  This app is fronted with an Apache web server which as a SiteMinder Apache web agent installed protecting this app.  On the policy server side we have an application Domain created for this app which has a Agent/ACO/Realm/Rule/Policy/Auth Scheme, etc,.


    If we decide to remove the Apache web server fronting this app and replaced it with an NGinx web server, which does not have a supported SiteMinder web agent and therefore we are forced to use the SPS to protect this app rather than the traditional web agent, what would my process be in this scenario?  I understand that the very first thing that needs to happen is to modify our DNS so that HTTP request to will no longer go to our Apache web server but instead it would resolve to an IP address that is bind to a virtual host on the SPS machine, but what about the rest of the flow?


    Once an HTTP request to:*  reaches the SPS vhost, is there some kind of ACO on the SPS that see this request and map it to a SiteMinder Agent which then map to the policy Domain realm?  I just feel like there is something very simple here but I am missing that connection with the SPS concept.


    Much thanks in advance,


    Duc Tran,

  • 2.  Re: New to CA Access Gateway - r12.52 SP1 CR05
    Best Answer

    Posted 02-15-2017 05:09 PM

    Hi Duc,


    Here is what you will need to do :


    1. Modify DNS resolution of from your old Apache webserver to SPS Host.

    2. Create new ACO for SPS agent using SPSDefaultSettings ACO. Copy over any important configurations from old Apache ACO like agentname/badcsschars etc.

    3. Create a virtual host for in SPS.

    4. Create a proxy rule (in proxyrules.xml or using Proxy UI) in SPS to redirect all the request for virtual host to your new Ngnix web server hosting your application.


    Sample proxyrules.xml


    <?xml version="1.0"?>
    <?cocoon-process type="xslt"?>
    <!DOCTYPE nete:proxyrules SYSTEM "file:///C:\Program Files (x86)\CA\secure-proxy\proxy-engine\conf\dtd\proxyrules.dtd">
    <!-- Proxy Rules-->
    <nete:proxyrules xmlns:nete="" >
    <!-- <nete:forward>$0</nete:forward> -->

    <nete:cond type="host">
    <!-- replace with a virtual host defined in the server.conf file -->
    <nete:case value="">
          <!-- replace with the appropriate destination server -->
          <!-- replace with a default destination used for all requests that do not match the nete:case elements -->





  • 3.  Re: New to CA Access Gateway - r12.52 SP1 CR05

    Posted 02-17-2017 11:39 AM

    Hi Ujwol,


    Thank you SO MUCH for this response.  This helps me out a lot.  So there is already a "default" ACO path for the SPS under: [sps_path]/ca/secure-proxy/proxy-engine/conf/defaultagent so for my new vhost (, how do I assign this new vhost to the new ACO and likewise as I create more vhosts to host new sites?

  • 4.  Re: New to CA Access Gateway - r12.52 SP1 CR05

    Posted 02-20-2017 11:16 PM

    Hi Duc,


    Sorry for the delayed response.


    You can create new virtualhost and associate ACO(WebAgent.conf) either via ProxyUI or manually.

    Refer to the screenshot below where I create a new virtual host for and associate a new WebAgent.conf to it.


    Step 1. Create a copy of defaultagent folder and rename to ourappagent. You can then modify the WebAgent.conf file to point your new ACO. Note, multiple virtual host can refer to the same default WebAgent.conf, so this step is optional.

    Step 2. Login to Proxy UI --> Virtual Hosts and Click Add button

    Step 3 . Provide all the required details for your new virtual host in the config wizard as below:


    So , in terms of configuration file what we have effectively done is added this new virtual host entry for in the server.conf as below :



    Hope this helps.



    Ujwol Shrestha

  • 5.  Re: New to CA Access Gateway - r12.52 SP1 CR05

    Posted 02-24-2017 12:09 PM



    Thank you for the help on this, much appreciated your extended help getting me started on SPS.  Over the last few days I had been playing with the proxyrules.xml file along with server.xml and was able to successfully setup several proof of concept case scenarios.  This process gave me a good initial understanding of the SPS framework.  Next step/level of exploring SPS is to figure out how to implement SPS to protect various independent web applications over SSL and with load balancers in front and behind SPS.

  • 6.  Re: New to CA Access Gateway - r12.52 SP1 CR05

    Posted 04-28-2017 02:01 PM

    Hi Ujwol,


    I am revisiting the Secure Proxy Server again and wanted to confirm something with you on the steps to move an existing web app with traditional web agent to be protected by SPS.  Previously you mentioned that I would need to create a virtual host in the "server.conf" file and then create a proxy rule in the "proxyrule.xml" file, but what about the Apache part?  I would still need to create a new Apache "Virtual Host" within the SPS Apache to listen for the incoming HTTPS request correct?


    My current app is: so to move this to SPS I would also need to modify the "httpd.conf" file and add a virtual host below:


            SSLEngine on
            SSLCertificateFile /usr/pservices/ca/secure-proxy/SSL/certs/spstest-dev.crt
            SSLCertificateKeyFile /usr/pservices/ca/secure-proxy/SSL/keys/spstest-dev.key
            <Directory /usr/pservices/ca/secure-proxy/httpd/htdocs>
            Require all granted
            AllowOverride All
            DocumentRoot /usr/pservices/ca/secure-proxy/httpd/htdocs


    So lets say if I need to add 20 new web sites to be protected by SPS, so aside from adding the "virtual host" for the server.conf file, I would need to do this for each and every new app that is going to be protected by SPS?  If so then I would need to assign 20 new IPs to the SPS server host for the SSL binding and modify the httpd.conf file adding 20 virtual hosts for each of those sites and maintain the SSL certificates on the server?


    Thanks and advance,


    Duc Tran

  • 7.  Re: New to CA Access Gateway - r12.52 SP1 CR05

    Posted 08-17-2017 09:44 AM

    I am new to Access Gateway, and I do have a question on similar lines. If we need to protect 5 applications using access gateway, then do we need to have 5 instance of access gateway in same SPS host or can we have 1 instance of access gateway for protecting 5 applications?

  • 8.  Re: New to CA Access Gateway - r12.52 SP1 CR05

    Posted 08-17-2017 02:54 PM

    Hi Lakshman,


    A quick answer to your question is, yes you can protect multiple application/web sites with a single installation/instance of Access Gateway.  We started to explore Access Gateway as an alternative to the web agent because CA does not provide a web agent for Nginx web server.  We installed and configured an installation of Access Gateway as a proof of concept to see how well it would integrate with our complex infrastructure but ultimately determined that the Access Gateway product will not work out well for our needs due to the nature of the design of this product (Reverse Proxy Server).

  • 9.  Re: New to CA Access Gateway - r12.52 SP1 CR05

    Posted 08-18-2017 02:06 AM

    Hi Duc,

    Thanks for your quick response.

    Did you get a chance to try out the PWP developed by GD team for Nginx agent?

    CA Global Delivery Packaged Work Product Download Index - CA Technologies 

  • 10.  Re: New to CA Access Gateway - r12.52 SP1 CR05

    Posted 08-18-2017 11:10 AM

    Hi Lakshman,


    Yes, we looked into this.  This is CA's "Global Delivery" product and the pricing structure for it is very expensive.