Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > Authors Jason Wilcox

CA Single Sign-On

2 Posts authored by: Jason Wilcox Employee

As a senior architect with CA Services, I collaborate with a lot of customers on their security environments. Lately, I’ve noticed that CA Access Gateway (formerly CA Secure Proxy Server), which is a component of CA Single Sign-On (CA SSO), is quickly becoming the mechanism of choice for enforcing CA SSO policies. Not only does it allow our customers to consolidate agents, which makes it easier for them to manage their environments, but it’s also their platform of choice for extending CA SSO’s functionality.

 

While our traditional CA SSO Web Agents continue to receive updates to support new platforms and ensure the security of customer environments, CA Access Gateway has seen enhancements like authentication and authorization web services, integration with Office 365, a purpose-built STS, enhanced session assurance, and most recently, services that support OAuth- and OIDC-based applications.

 

CA Access Gateway’s growing value makes it more and more important to monitor it, ensure that its performance meets SLAs, and see that it delivers the optimal customer experience. For years, CA Application Performance Management (CA APM) customers have had the benefit of an APM product that can be integrated with and is specifically dedicated to CA SSO. What has been a well-kept secret (one I’m determined to spread the word about) is that all the way back to version 12.5, CA Access Gateway could natively integrate with CA APM.

 

While CA SSO Policy Server and agents need a plug-in, CA Access Gateway needs to point to an EP agent application to report base web agent statistics, including:

  • User and resource caching
  • Bad and expired cookie hits
  • Bad URL and cross-site scripting hits
  • Standard web agent operations (Is Protected, Authorize, Validate, Logon)

 

These statistics are great for understanding the web agent side of Access Gateway, but we also need to understand the proxy’s other operations. So with this integration, CA APM can also report on:

  • The number of proxy rules files
  • SPS wait time
  • Average HTTP client time
  • Average Java web agent time
  • Average post-agent session write
  • Average proxy rule filter time
  • Average session discovery time
  • Average response time from back-end servers

 

It’s Even Simpler Than 1-2-3

Enabling the built-in monitor is as simple as a two-line change in the server.conf, where you will find the configuration fragment:

<metric-reporter name="WilyMetricReporter">

                class="com.ca.proxy.monitor.wily.WilyMetricReporter"

                enabled="no"

                endpoint="http://localhost:8886"

</metric-reporter>

1.   Change enabled="no" to enabled="yes"

2.   Change endpoint="http://localhost:8886" to endpoint="http://<EPAgent Endpoint>"

 

The endpoint can be any EP agent, although pointing it to a local EP agent would give you the rest of the local machine data. Upon restart, your enterprise manager will give performance and health data from CA Access Gateway. This enables you to baseline your performance, build alerts, and integrate the data into your performance management plans.

 

Inquiring minds want to know: Do you use APM for monitoring your CA Single Sign-On environment? If not, does it sound like a clever idea, or do you have a better idea? Let us know your thoughts!

CA Single Sign-On (CA SSO) has long had the capability to define an agent name in two ways: You can use an agent identity to map the agent name to an FQDN or IP address, or you can use DefaultAgentName. Many of our customers use both methods.

Agent identities have traditionally been used to provide a unique agent for each virtual server on a web server. This allows each virtual server to have policies that are unique to it; it also allows the application’s business requirements to reside on the server.

Alternatively, DefaultAgentName is configured when there are no virtual servers or they don’t need unique policies. DefaultAgentName is also often configured as a catch-all in addition to agent identities. The idea behind this tactic is that if CA SSO can’t determine which agent identity to map a request to, it will use DefaultAgentName. As a result, any request coming to the web server will be processed and the user will have a good experience, right?

Wrong!!

 

While on the surface this seems reasonable, when you dig under the covers a little, this is actually alarming. When a request comes to a web agent, the web agent attempts to map the incoming hostname or IP address to the configured agent identities. The result is an agent identity that may look like this:

If those agent identities were the only agents configured, only requests that came to that hostname and those two IP port combinations would be protected. Anything else on the server would be unprotected. That may be by design, but best practices state that we should deny by default, not, as we’re doing here, allow by default, which protects only listed virtual servers.

 

To solve this challenge, CA SSO has two agent parameters: DefaultAgentName and IgnoreHost. DefaultAgentName becomes that catch-all for requests to the server that the web agent can’t map directly to an agent object in the policy store. This is very useful from security and monitoring perspectives. IgnoreHost allows you to create a list of hostnames that you want the agent to ignore and not manage at all. When you use both parameters, DefaultAgentName allows you to deny by default any undefined host that somehow arrives at the server, and IgnoreHost allows you to ignore hostnames you know are mapped to the server but that you don’t want the CA SSO web agent to manage.

 

The final piece of the puzzle is creating a common set of policies and error redirection for anything that hits DefaultAgentName. Because we map all managed hostnames to an agent identity, and we use IgnoreHost for all known unmanaged hostnames, everything else should be considered an error and handled as such.

I like to define DefaultAgentName as an agent named “HostError” for each ACO. I then map “HostError” to a set of policies that redirect requests to a common error page and ensure that I capture the incoming hostname that caused the redirection. This allows for quick analysis of misconfiguration of DNS or the web server or identification of malicious attempts to bypass the web server’s security.

 

Inquiring minds want to know: Do you have standards in place that define when to use an agent identity vs DefaultAgentName? Do your standards take into account security best practices such as deny by default? Why or why not? Let us know!

 

I am a Sr. Services Architect with CA Services. Interested in learning more about CA Services expertise in the security space? Click here or comment below.