When an application breaks and we hear things like, “My login is not working,” or “The web app is slow,'' more often than not SiteMinderTM seems to be in the line of fire. However, in my experience, it has usually been a third-party or other configured item like firewall rules that have turned out to be the culprit. Now I am not saying that it is never SiteMinder. Potentially the issue could be anywhere, but I guess the bigger question here is how do we prove it one way or the other?
Before we dive into how we can help security and application teams answer the question, “Where is the problem?” let’s look at SiteMinder’s reference architecture.
SiteMinder provides secure single sign-on (SSO) and flexible access management to applications and web services on premises, in the cloud, from a mobile device, or at a partner’s site. It is critical for flawless delivery of business-critical applications.
The Access Gateway is the entry point, routing the traffic depending on whether the resource is protected or not and also if it's available in cache or not. Depending on that, the request may then go to the policy server. There can be numerous decision points. In most cases, a user entitlement store like SAML or LDAP is also present and interacts with the policy server for user authentication and authorization rules.
SiteMinder sits in between users and the application for secure access. Given that, it is important that a monitoring system keeps an eye on the critical flow between these endpoints. It should have the ability to observe and record the availability and performance aspects and report any errors or anomalous behavior proactively. This system should be sophisticated and purpose-built by experts who understand SiteMinder really well.
At a very high level, DX APM for SiteMinder is a combination of DX APM plugins that are shipped with these SiteMinder components: Access Gateway, Policy Server, and Web Agent. They extract key performance metrics from these components and report to the DX APM Infrastructure Agent (APM IA), which collects and forwards the data to DX APM SaaS. These out-of-the-box plugins are shipped with SiteMinder, which eliminates the need to go through the trouble of downloading and installing them separately. Plugins only have to be enabled and configured to send the monitoring data to the DX APM instance.
DX APM also provides out-of-the-box alerts and dashboards. With out-of-the-box plugins, metrics, alerts, and dashboards, monitoring SiteMinder becomes really easy and quick to set up. It also correlates the metrics and alarms to identify where the actual problem is that needs to be fixed. For example, some of the out-of-the-box policy server metrics measure the policy server queue length, response time, database average response time, and so on. Similarly, on the gateway and the web agent, it monitors the response times, the loads in transactions per second, etc. DX APM not only provides these metrics in a single view for visual correlation but also presents performance breach alarms. Here, it also correlates the alarms, which can then be used for faster triage and remediation.
IT operations and security teams follow different workflows at different enterprises. Some use ”follow the red” on a dashboard, while others prefer to get notified of a problem based on the severity. And then, of course, there are teams that leverage the best of both workflows. Firstly, regardless of the standard procedures, teams often struggle to find the root cause and reduce the mean time to identify the real problem. Secondly, IT operations teams and security teams often find it challenging to collaborate because they lack a unified view of monitoring data.
DX APM provides a platform to foster collaboration through role-based access and privilege control. So, in a scenario where the policy server queue length spike is affecting the average response times, both security and IT operations teams can view the same performance metrics and create tickets, assign problems, and notify the right team with the contextual information required for triage. This creates a self-service environment for the responsible teams, driving accountability and laying the foundation to automate mundane issue triage and remediation.
At Broadcom, apart from the quick time to value as described above, we also recognize that sometimes you do come across new needs or gaps. Both the DX APM and SiteMinder teams work in close collaboration and address those gaps as can be seen from the screenshots below. Metrics like URL timing is a good example of such collaboration. In this case, the log from FWTrace.log is parsed and KPIs extracted and reported to DX APM. The same applies to CA Directory and Host TCP Queue metrics.