Symantec Access Management

 View Only
  • 1.  CA SSO 12.8 WAM UI Registration and Login Flow

    Posted Nov 04, 2018 11:28 PM

    Hello All,

    Here I have added my scenario on CA SSO 12.8 WAM UI requirement.


    1. We have implemented CA SSO 12.8 in AWS environment. Policy server runs under ELB and WAM UI separated from policy server layer due to access restrictions under the layer of policy server. Hence, I have installed and configured on the layer 1, where secure proxy server runs on. 


    Here is the problem:

    XPSRegClient will be run on policy server layer. Lets take the example of following case.


    Layer 1 (SPS+WAM UI server) ------> ELB----> Layer 2 (PS1+PS2)


    On PS1 policy server I have registered the WAM UI client.


    PS1#/opt/CA/siteminder/bin/XPSRegClient <administrator>:<phaseprase> -adminui-setup -vT


    WAM UI installation and configuration is completed without any problem and able to see WAM UI login page which prompts three files.


    1. Username : <administrator>

    2. Password : <Password>

    3. Server     : ??????????????????????


    what is the server name suppose to be here ? is that ELB or PS1 host name ?


    I have tried both but with these two values I am getting following error.

    Error: No registration on file.


    Questions here:

    1. How WAM UI server establish the trust with policy server ? is there any config file on the wam UI server ? If yes what i that and how that's generated  ?


    Please help me with right documentation to segregate the WAM UI and policy server. 




  • 2.  Re: CA SSO 12.8 WAM UI Registration and Login Flow

    Posted Nov 05, 2018 01:16 AM

    This has to be individual policy server and thats working . However I am not sure why we cannot provider ELB DNS which can distribute the wam ui request to available policy servers.


    My next question on the same context is,


    We have three fields as part of WAM UI,


    username : <client name>

    Password: <Password>

    server: 111.222.333.444


    First time, I have entered server name as as 111.222.333.444 and next time I wanted to connect with another policy server in the stack. for instance, 555.666.777.888.


    However, what I have noticed is, wam UI login screen server name parameter not editable and field converted as drop down instead of text box. how do we remove this tightly coupled behavior.

  • 3.  Re: CA SSO 12.8 WAM UI Registration and Login Flow

    Posted Nov 05, 2018 10:13 AM

    What is the server name suppose to be here ? is that ELB or PS1 host name? This should be the FQDN of the Policy Server you did the xpsregclient on.

    Have you checked to make sure that the xpsregclient was created on the Policy Server? It would be located on under CA/siteminder/bin directory. 


    We use Windows Servers for our setup so I have never done a setup on Linux. But did you run the SSO Administrative Console to make this connection for the first time? Or did you access the AdminUI from the URL?

  • 4.  Re: CA SSO 12.8 WAM UI Registration and Login Flow

    Posted Nov 05, 2018 05:55 PM

    Dear Brain,


    Thank you for your information.


    Yes, I can access WAM UI using FQDN of policy server where I have registered WAM UI Client.


    To answer to your question, we are using linux and we haven't enabled management console with out setup and accessing the WAM UI with URL.


    Can you please help me to understand, how do we refer policy server FQDN when aws auto-scaling in place ? Since we haven't enabled DNS to policy server layer due  to its auto spinup features.


    another question,

    1. How can we connect to different policy server when my WAM UI is not allowing me enter another IP address. (please check attached image server name where server name shows as drop down)

  • 5.  Re: CA SSO 12.8 WAM UI Registration and Login Flow

    Posted Nov 05, 2018 05:55 PM

  • 6.  Re: CA SSO 12.8 WAM UI Registration and Login Flow

    Posted Nov 06, 2018 09:04 AM

    I can't help with the AWS scaling part as I have never used it. When AWS scales do you get the same server names or are they randomly generated at time of spin up? 


    To add additional Policy Servers you need to first link the AdminUI to an outside directory and create a new Admin User Account:

    Then once that is done you can go to the same place and use the Policy Server Connections to add additional Policy Servers. You will need to run the XPSRegClient on each PS you want to add prior to this step.

    Now if AWS randomly generates server names when it scales I don't know how you would accomplish this. The only thing I have scaled in regards to siteminder is the Web Agent in a test Docker environment.

    Sorry I couldn't be of more help. Have a great day.

  • 7.  Re: CA SSO 12.8 WAM UI Registration and Login Flow

    Broadcom Employee
    Posted Nov 06, 2018 12:59 PM

    Though you register all the Policy Servers with AmdinUI, you will be just using only one adminui in real time scenario.


    @brian.w.jones suggested an officially supported way to register multiple policyservers with an AdminUI.


    Configure an External Administrator Store - CA Single Sign-On - 12.8 - CA Technologies Documentation 


    Here is a workaround which is not officially supported by CA. You may give it a try at your own risk.


    Workaround to register an admin UI with multiple policy servers 


    An another option is, you can have a dedicated server for hosting AdminUi alone and register it with multiple policyservers as you need(remember you need to externalize authentication as Brain mentioned above). Only caveat is you need to register/de-register as your environment scales Up/Down.

  • 8.  Re: CA SSO 12.8 WAM UI Registration and Login Flow

    Posted Nov 06, 2018 09:56 AM



    May I understand what do you mean by "due to access restrictions under the layer of Policy Server". 


    Typically for security reasons and best practices followed in industry, one has to segregate end user txns / traffic and management txn / traffic. This is true for networks and so is for software as well. We should not allow management traffic to be routed in the same way as End User Traffic.


    Access Gateways are primarily to cater end user txns / traffic, as such they are best poised to be placed in DMZs. 


    WAM UI is management / administrative txn / traffic. By applying the same rules as the Access Gateway (deploying WAM UI exactly the same way as CA Access Gateway), we are not only complicating the overall solution, but also going down a path which will end up breaking the management / administrative function.


    To start off you need to segregate Transactional Policy Server's and Administrative Policy Server's. We can scale transactional policy server's as needed behind the ELB. Transactional Policy Server's only have Policy Server service running on them and take in ONLY end user traffic from CA Access Gateway. 


    Administrative Policy Server on the other hand has a Policy Server Service running and WAM UI running. The WAM UI running on each Administrative Policy Server is registered only to that Policy Server running on the same box. For scaling Administrative Policy Servers, we'll have to bring up more servers which has WAM UI + PS on the same box. Administrative Policy Server's has a mandatory 1:1 relationship with Policy Server and WAM UI on the same box. This will ensure that each WAM UI is speaking to its own Policy Server and thus has no dependencies on external factors like Session Stickiness (with ELBs).



    Lastly, I'm not sure if you have signed up for and R14.0 Beta, which has Policy Server & WAM UI in containers. That design follows the above thumb rule.

    • Hence as a product we are driving the strategy to be in two paths for Policy Server i.e. Administrative Policy Server and Transactional Policy Server.
    • As per this design, we would not support connecting to different Policy Server infrastructures using a single WAM UI, as we currently do in the External Administrative UI mode.
    • I think we will support External Administrative UI, but just that each WAM UI would be connected to its own Administrative Policy Server and the Policy Server inturn would be connected to its embedded Policy Store.
    • So there is a ton of design changes and conceptual changes, all strategically aligning to containerized deployment strategies. I'd recommend and welcome you to review the discussions on "".





  • 9.  Re: CA SSO 12.8 WAM UI Registration and Login Flow

    Posted Nov 06, 2018 07:13 PM

    Hello Hobert,


    Thanks for your response.

    Let me portrait my scenario here.

    1. We are building CA SSO 12.8 in AWS platform. There are three layers when it comes to design. Tier 1 SPS (DMZ Zone), Tier 2 Policy server (Only Tier 1 can be allowed as inbound connection to tier 2) and last tier 3 which is the user store and policy store.

    Hence, we cannot access the WAM UI when its installed with policy server host which sits on the tier2 and we cannot access wam ui directly for management activities. So we wanted to separate WAM UI and policy server in different layer. 


    Now we wanted to establish the connectivity to policy server which sits beyond the ELB considering all the policy servers registered for the adminui client.


    Hopefully this clears the scenario.

  • 10.  Re: CA SSO 12.8 WAM UI Registration and Login Flow

    Posted Nov 06, 2018 08:54 PM



    Am going to hijack the discussion to something else to get the mind cracking, but I'm going to stick to the concept of CA SSO Administrative Policy Server (Weblogic Admin Server with Weblogic Console) and CA SSO Transactional Policy Server (Weblogic Managed Server).


    WebLogic 12c Enterprise Deployment Architecture in the Amazon Cloud - Oracle Middleware Blog  


    If I take a look at this blog, an example of Weblogic Admin Server (with Admin Console) and Managed Servers, this is deployed in Tier-2. It seems it is very much doable for CA SSO Administrative Policy Server's and CA SSO Transactional Policy Server's. Albeit I haven't done it, but if I start putting CA SSO components instead of Weblogic components and start following the set standards, it should be achievable.


    The key question I'm asking myself through this entire exercise is from an AWS Architecture perspective

    1. What is the difference between Weblogic Administrative Console and CA SSO Administrative Console.
    2. If Weblogic Console can reside and function from Tier-2, with a WebServer Proxy on Tier-1, why can't CA SSO Administrative Policy Server (WAM UI + Policy Server on a single EC2 instance of its own).


    For starters here are key take aways.


    • The architecture leverages features like the AWS Auto Scaling Groups to automatically scale up or down, based on metrics that are collected from the system, such as CPU or memory consumption. WebLogic 12c Dynamic Cluster feature makes it very easy to instantiate new managed servers in the cluster when application traffic demands it.
    • As per the Fusion Middleware EDG, this virtual network will have a public and a private subnet. The webservers will have IP addresses from a public subnet, routable in the Internet, and both ssh connections to the EC2 instances hosting the webservers as well as incoming HTTP traffic will be allowed. The application servers however, will have IP addresses from a private subnet. That means that only the webserver instances will be able to connect to the application server instances on specific ports. The WebLogic Administration Server will run on its own EC2 instance, and a dedicated EC2 instance will host each WebLogic Managed Server in the architecture. Traffic between the Admin Server and Managed Servers is completely open, within private subnets.
    • All traffic is allowed between the Admin Server and Managed Servers, but traffic between web server (public subnets) and the WebLogic servers (private subnets) is limited to ports 7001 for the Administration server and 7101 for Managed Servers.
    • In a running Production environment the Admin Server Auto Scale Group would have the desired, minimum and maximum values all set to 1, since there can only be 1 Admin Server for a WebLogic domain.
    • The LBR in front of the web servers has a public IP address. The WebLogic servers Auto Scaling groups, the one for the admin server and managed servers respectively are front ended by internal Load Balancers. To secure the architecture, each Load Balancer has a Security Group attached to it. For example, the internal Load Balancers will only accept incoming traffic from the web servers, and route all requests to the WebLogic server in the application tier.
    • After creating and configuring the components all that is left to do is to start up the WebLogic servers on AWS and test the connectivity to the administration console and any deployed applications. It is then enough to edit the Desired value of the wls12_admin_scaleGrp to 1 to start one EC2 instance which will host the WebLogic Admin server. To make it publicly accessible, at least another separate EC2 instance for the web server needs to be started. As well, just by editing the scale group to have the desired number of instances. Once the EC2 instances are initialized, the Launch Configuration will start the WebLogic services. When they are running and listening on the ports the Load Balancers are performing the Health Check on (7001 for the administration server and 80 for the web servers) the administration console is accessible on the Internet.



    Public ELBTier-1Internal ELBTier-2Internal ELBPStore
    Internet FacingCA Access Gateway (with Virtual Host for WAM UI hostname e.g.


    Sticky Session enabled. So that traffic is sent to a single Administrative Policy Server i.e. if there are multiple Administrative Server's.

    Administrative Policy Server's


    EC2 Server-1 : Single WAMUI registered with Single Policy Server on a single EC2 Server.


    EC2 Server-2 : Single WAMUI registered with Single Policy Server on a single EC2 Server.

    Route TCP Traffic to PStore-APStore-A



    I think so this is very much doable, if we adopt the same concept of how a Weblogic Cluster is deployed in AWS.



    Design Consideration : You need to have Administrative Policy Server Infrastructure for each ENVIRONMENT i.e. You cannot use the same Administrative Policy Server to connect to different Policy Server Infrastructure / Policy Stores. This is the future design from R14.0 as well.