Symantec Access Management

We had deployed web applications on AWS before with Apache web server and the AWS classic load balancer and this setup seemed to be working fine.  We then switched out the AWS classic ELB load balancer to use the ALB (Application Load Balancer) and now encountering an issue with the web agent.  Here is the specific of the issue:

With the SiteMinder web agent "Disabled" below is the normal expected behavior:

1) with the web agent "Disabled", we request: https://www.company.com

2) the web request goes to the AWS ALB load balancer

3) the load balancer send the request to one of the several Apache web servers in the pool member.

4) The web URL still remain at https://www.company.com and the web content is display from the Apache web servers.

With the SiteMinder web agent "Enabled", below is the behavior:

1) user request https://www.company.com

2) the web request goes to the AWS ALB load balancer

3) web agent redirect browser to IWA auth scheme

5) IWA auth scheme completed user authentication and creates SMSESSION cookie

6) web browser is redirected to AWS server name: https://internal-chp-adif-sm-sso-dev-1108094247.us-west-2.elb.amazonaws.com as the web URL rather than https://www.company.com

We had tried so many different ACO and Apache configuration settings, but cannot figure out why the web agent will change the web URL from the initially requested URL of the load balancer to server's host name.  Below is a snippet of the agenttrace, but please see the attached agent.log and agenttrace.log files:

[09/24/2018][22:58:58][15818][2485028928][CSmHighLevelAgent.cpp:322][ProcessRequest][70ab350c7e9e0ea85ed5238f761eb4c8-3dca-5ba96c32-941e8840-ae2e73d2b076][][][][][][Start new request.]
[09/24/2018][22:58:58][15818][2485028928][CSmResourceManager.cpp:75][CSmResourceManager::ProcessResource][70ab350c7e9e0ea85ed5238f761eb4c8-3dca-5ba96c32-941e8840-ae2e73d2b076][][][][][][Calling SM_WAF_HTTP_PLUGIN->Proce
ssResource.]
[09/24/2018][22:58:58][15818][2485028928][CSmHttpPlugin.cpp:258][CSmHttpPlugin::ProcessResource][70ab350c7e9e0ea85ed5238f761eb4c8-3dca-5ba96c32-941e8840-ae2e73d2b076][][][][][][Setting FIPS MODE = 1]
[09/24/2018][22:58:58][15818][2485028928][SmApache24WebFilterCtxt.cpp:1744][CSmApache24WebFilterCtxt::SetP3PCompactPolicy][][][][][][][sP3PCompactPolicy: '']
[09/24/2018][22:58:58][15818][2485028928][CSmHttpPlugin.cpp:399][CSmHttpPlugin::ProcessResource][70ab350c7e9e0ea85ed5238f761eb4c8-3dca-5ba96c32-941e8840-ae2e73d2b076][][][][][][Resolved HTTP_HOST: 'internal-chp-adif-sm-
sso-dev-1108094247.us-west-2.elb.amazonaws.com'.]
[09/24/2018][22:58:58][15818][2485028928][CSmHttpPlugin.cpp:5340][Entered CSmHttpPlugin::ResolveFQServerName sHost: ][][][][][][][internal-chp-adif-sm-sso-dev-1108094247.us-west-2.elb.amazonaws.com]
[09/24/2018][22:58:58][15818][2485028928][CSmHttpPlugin.cpp:5536][CSmHttpPlugin::ResolveFQServerName, DNSLookups disabled, checking to see if cookiedomain added!][][][][][][][internal-chp-adif-sm-sso-dev-1108094247.us-w
est-2.elb.amazonaws.com]
[09/24/2018][22:58:58][15818][2485028928][CSmHttpPlugin.cpp:490][CSmHttpPlugin::ProcessResource][70ab350c7e9e0ea85ed5238f761eb4c8-3dca-5ba96c32-941e8840-ae2e73d2b076][][][][][][Resolved hostname: 'internal-chp-adif-sm-s
so-dev-1108094247.us-west-2.elb.amazonaws.com'.]
[09/24/2018][22:58:58][15818][2485028928][CSmHttpPlugin.cpp:509][CSmHttpPlugin::ProcessResource][70ab350c7e9e0ea85ed5238f761eb4c8-3dca-5ba96c32-941e8840-ae2e73d2b076][][][][][][Resolved agentname: 'aws_adifadmin-dev'.]
[09/24/2018][22:58:58][15818][2485028928][CSmHttpPlugin.cpp:5717][CSmHttpPlugin::ResolveClientIp][70ab350c7e9e0ea85ed5238f761eb4c8-3dca-5ba96c32-941e8840-ae2e73d2b076][][][aws_adifadmin-dev][][][Resolved Client IP addre
ss '10.51.156.147'.]

Hi Duc. Probably better off creating a support issue on this. 

Hi Terry,

I do have a support case open with CA, but I really don't think the support folks would be able to provide me much help on this particular issue.  I found a related discussion thread from CA Community on this and the outcome does not look very promising:

CA Support CASE: 01195925

https://communities.ca.com/ideas/235738320-aws-application-load-balancer-with-siteminder-web-agent

From this discussion thread it appears that CA is saying that the web agent currently does not support AWS ALB type of load balancer and suggest users to use the old/classic type of AWS load balancer.  If this is true then this will be a show stopper and will be the nail in the coffin for our organization with CA SSO because we are moving our web infrastructure into AWS cloud and the AWS ALB is the future of application load balancing.

I still feel that if we take a deep enough look into this issue we can find a work-around resolution to this.  It seems that the web agent is somehow picking up the load balancer's host name and use that as the TARGET/Location as it redirects the browser to an authentication scheme.  If I "unprotect" the resource/realm then the request does not get redirected to the authentication scheme so we don't see this behavior.  But if we protect the resource then the web agent redirect the browser to the authentication scheme and then build the TARGET value using the LB's host name rather than the initial requested URL/HOST.

RESOLVED

There was some recent architecture change affecting the routing of the application.  We recently introduced another layer of web server load balancing from the on premise side so now the browser web request to the application first goes to the on premise F5 load balancer then it is sent to the AWS load balancer.  The interactions between these two load balancers must have set the wrong value of HTTP_HOST value causing the web agent to redirect the browser to the host name of the second load balancer rather than the initial VIP address.