Idea Details

CA SPS : SPS ProxyUI Domain Creation

Last activity 06-03-2019 08:22 PM
HubertDennis's profile image
07-10-2016 01:02 AM

The current design for protecting SPS ProxyUI follows the approach of SPS Configuration Creating a Policy Domain for protecting the ProxyUI during the SPS Configuration process.


During the SPS Configuration Process, the configuration wizard accepts two values as input.

  • Agent Configuration Object Name.
  • Agent Name.


The Configuration wizard under the covers does the following two action.

  • Create a Policy Domain by making a SDK call to the Policy Server. The Policy Domain is created using this nomenclature DOMAIN-SPSADMINUI-<AgentName>.
  • Read the Agent Configuration Object from Policy Server. Check for values of LogOffUri and IgnoreExtn. If LogOffUri does not include /proxyui/logout - then add the value as this is the URI which does the ProxyUI logoff. Also it adds .css in IgnoreExtn to allow the stylesheets for ProxyUI to render successfully.



The fundamental flaw with this design is that on the field this does not work efficiently.


  1. We often see failures in the step when the configuration wizard tries to create Policy Domain and / or update ACO.
    • Example : Customer has Load Balancer between SPS and Policy Server. Customer uses VIP IP in configuration wizard and HCO. The SPS Configuration Wizard complains of failure.
    • Example : Customer has PStore on a lower version. The SPS Configuration Wizard complains of failure.
    • Example : Customer has defined multiple IP addresses in SPS Configuration Wizard and HCO. The SPS Configuration Wizard complains of failure.
  2. Each SPS Configuration creates a new redundant duplicate Policy Domain.
    • In the field Customer do not like the approach of having one policy domain per SPS. Customers delete the duplicate Policy Domains, then create a AgentGroup for a single Policy Domain. Then map all SPS agents to that one single Agent Group (This is similar to CA SSO strategic design which is adopted for FederationWebServices Policy Domain).
    • Therefore our design of SPS Configuration Wizard inherently is adding more work out for Customer than simplifying it.
  3. New features are necessary to compete in the open market. However standing / footing on stable ground is also necessary.
    • If man hours are being spent on Customer end and CA resources (Support resource, Services resources and Engineering resources) repeatedly for the same issue. Then this is a indicator we are not doing something right. It needs to be prioritized and fix the problem, even if it is a petty issue & we have manual workarounds to create objects / do manual updates.
    • If we are trying to use SPS to implement a marquee feature (e.g. STS or AuthAzWebServices OR SessionAssurance or WAOP). Then then SPS Configuration spews failure at the onset even before configuring the feature, that is not a good showcase of stable ground.


I personally have encountered this same issue at multiple customers.Two of the case below have been raised by myself whilst working with two different customers on customers own environment.


I pulled out a list of Support Cases that have been raised for the very same issue.




Case NumberSubject
444674SPS : Creation of ProxyUI protection failed.
130810Creation proxyui objects fail
64735SPS - Proxyui protection fails
10641ProxyUI protectionpolicy faile
322091SPS registration calls fails via LB
345337Registering SPS Fails
280910SPS 12.52 SP1 CR04 install
220374AAS for SPS




I feel we can redesign this in an efficient manner.


Instead of doing SDK API calls and updating to Policy Store via SPS Configuration Wizard. We should look at shipping....

  1. SPSDefaultSetting ACO with all default values for SPS pre-populated. I already have a ER for this.
  2. Create a new XML file similar to smpolicy.xml or ampolicy.xml (e.g. spspolicy.xml). This would ensure we have a generic one Policy Domain which protects all ProxyUIs on all SPSs.
  3. Ship spspolicy.xml with SPS kit and PS kit. Such that during upgrade OR fresh install the spspolicy.xml is available to customer even though the customer only upgrades SPS and not necessarily the Policy server.
  4. spspolicy.xml should create
    • Policy Domain
    • AgentGroup
    • AuthScheme
    • SPSDefaultSettings ACO.






07-12-2016 04:40 PM

Linking a linked ER as both needs to be looked with a single strategic outlook towards resolution.

CA SSO : Enhance SPSDefaultACO to include all necessary values