We are moving our web applications onto the AWS cloud with dynamically scaled environment meaning that the servers could be deleted or created as needed based on application traffic demands. Each time a server is "created" an automation script is run to build the entire server stack including the installation of the Apache web server along with SiteMinder web agent installation and configuration.
Where we running into issues here is the registration of the Linux trusted host to the policy server. We found this documentation - - > https://docops.ca.com/ca-single-sign-on/12-6-01/en/configuring/policy-server-configuration/agents-and-agent-groups/use-web-agent-in-dynamically-scaled-environment/ that describes a solution for this scenario, but it seems a bit complicated and involves coding.
This is our proposed idea:
We would have up to three different Linux server/trusted hosts for a given application but at times we would delete one or two servers and then build new servers up on the fly when application traffic demand is high. Our question here is that if we plan to have a maximum of three (3) Linux server/trusted hosts for an app then we would use only three trusted host names to be registered to the policy server, meaning that Linux server #1 will always be assigned to a trusted host name "server-1-trusted_host" so that if this server is deleted and then later re-created then it will always use this smreghost command parameter - - > /etc/siteminder/webagent/bin/smreghost -i [linux-server-hostname] -u siteminder -p [pw] -hn server-1-trusted_host -hc smpolicyserver_hco -o
Next week this server may be deleted and the trusted host "server-1-trusted_host" would be an orphaned object in SMPS but later when the server is created again we would run the exact same smreghost command to overwrite the existing trusted hosted that is already registered on SMPS. Likewise for "server-2-trusted_host" and "server-3-trusted_host" each of those server will always use their specific smreghost command which will always assign the same trusted host name for the policy server.
The reason why we want to post this to the community is to see if folks would approve this approach and foresee any potential issues.
Much thanks in advance for your input!
The concept in dynamically scaled ENV configuration, is to move away from one trusted host object per WebAgent/WebServer instance.
If you are on R12.7 or R12.8 you can also use REST API to go around the complete coding aspect, though there would be level of scripting to support automation.
Hello Hubert, thank you for your fast response.
Can you elaborate a little bit and help me understand thas statement/explanation in your response: "Reusing Trusted Host for a Logical Application"? Basically we would have a set of individual Linux servers for a particular application/environment and at any given time we can expect a particular server/trusted host to be completely deleted and at a later time be replaced by a brand new server and this new server will go through the entire automation scripting process as it's predecessor
1) run SM web agent binary installation
2) run "smreghost" - - > reuse the same trusted host name of the previous server with the "-o" param to overwrite
3) run "ca-wa-config" - - > use the same/existing ACO/agent assigned to the application
So if a particular application has a set of three Linux web servers for high availability/performance then we would "reserve" three trusted host names and each of those trusted host names will be assigned to each of those three servers and at any given time those three servers could be deleted and then re-created then register with the same trusted host name.
Our thought process in Use Web Agent in Dynamically Scaled Environment - CA Single Sign-On - 12.6.01 - CA Technologies Documentation is that; we would not be generating trusted host based on per server. We would be generating a trusted host per application. All the WebServer's / WebAgents under this application would use the same TrustedHost and SharedSecret. So this TrustedHost only gets deleted if the applications gets decommissioned. This TrustedHost object is never deleted OR must not be overwritten when provisioning OR deprovisioning servers. The basic idealogy is when using a Cloud env, the pace at which new servers are provisioning OR deprovisioned is tremendous and uncontrolled in a way. In such circumstances if we adopted the native approach of one TrustedHost per Server, then we would not be able to keep up with the pace of cleansing the Policy Store of redundant TrustedHost objects. Thus causing other cascading issues in terms of store corruption and/or failed WebAgent-PS handshakes.
Having said the above, if in your organization, you have a controlled pace of provisioning and deprovisioning; then the approach laid out by you would work. But that approach is native approach of one Trusted Host per WebAgent. In that case what ever is defined in the documentation for "Dynamically scaled Environment" is not applicable. As we are following the traditional model which is still a valid model for onpremise solutions. The caveat we'd need to understand is when we are going to re-register using the same TrustedHost name with "-o" flag, the existing TrustedHost would be overwritten and a new SharedSecret would be generated. Hence if by any mistake there is another WebServer/WebAgent using the same TrustedHost-SharedSecret, that'd stop working.
Thanks for the explanation, very much appreciate it. This move to the cloud environment is an early stage and the dynamic environment scaling is also an early concept. For now we just need to be able to handle the scenario where we could expect having a web server/agent being deleted "occasionally" rather than rapidly, so I think we could still go with the "traditional" trusted host registration method as I described below for now.