Jaime Pérez Lyon, February 2011

Goals –The ability to monitor the status of the Identity and/or Service Providers of a working federation. –To have a monitoring platform that allows us to manage alerts, reports, graphs, statistics, and so on. Requisites –It must be compatible with our running infrastructure, based on Nagios. –It must be independent of the underlying technology.

Challenge 1: find the suitable tools –We started looking for the most suitable tools to fit the requirements. More specifically, we had the need of some software that allows automation of the user’s (and his web browser) behaviour. –We made our choice to be Apache Jmeter. Originally intended as a load testing tool, it’s perfect to simulate and evaluate navigation through web applications, and though its lack of support of Javascript, it provides mechanisms to sort it.

How does it looks like?

Automated use of JMeter –First we developed a test plan that simulates a login through our federation, authenticates and returns back to a specially crafted SP. –Then we used this test plan to run it in a dedicated machine by means of the JMeter command line interface. –We also considered using a farm of JMeter servers that receive the test plans and run them.

Automated use of JMeter –Since it is desirable to have just one plan for all IdPs monitored, we designed it with macros and variables that we change runtime to fit the specific detail of each IdP. That is: –Username –Password –The names of the input fields of the login form –A cookie to bypass the WAYF and go directly to an IdP from it.

Challenge 2: integrate with Nagios –Once we were able to test individually each IdP, we needed a way to run the tests and get the results in a specific format suitable for Nagios. –We developed a shell script that receives as command line parameters the variables mentioned before, modifies the test plan on runtime, runs JMeter with it and evaluates the output to translate to a Nagios service status/performance data.

Challenge 2: integrate with Nagios –It is flexible enough to allow us evaluate the settings of and IdP. For instance, looking for some mandatory attributes and triggering a warning if any of them is missing. –It also allows us to perform security tests, like making sure a non-existent user is unable to successfully login to an IdP.

Achievements 14 IdPs already being monitored and increasing

Achievements

To sum up: –User experience based federation monitoring: we simulate users and browsers, so if the monitoring says an IdP is working, then we can guarantee it is really working. –Technology independent: though it is adapted to our running infrastructure, it doesn’t know anything about the underlying technology, and in fact supports several protocols mixed altogether. –Want more info? Ask for the extended abstract!