SSO Support for Busy IT Admins 4 — Monitoring

So, that’s it… you’ve been given the weighty responsibility of SSO support for your organization. Or perhaps you’re new to the IAM team. Now what?

This post is the fourth in five-part series on the Fundamentals of SSO Support for IT Administrators.† You can see our first post here, our second post here, and our third post here, and our final post here.

Keeping Tabs on Your SSO Environment

A proper monitoring regime really gives you two – separate but equally important – tools:

• You’ll more quickly be able to access critically important debugging information when new, unexpected errors arise.
• You’ll be able to generally keep apprised of what’s going on… i.e. pro-actively tackling issues before they become serious, or more likely, start to gather the attention of users.

Let’s discuss each, in turn.

Know Your Logs

You would be surprised how many technical leads we encounter on a day-to-day basis that either don’t know what information is logged where, or don’t know how to properly tune their logging to get the information that’s relevant to the problem at hand.

My apologies if this post is somewhat Shibboleth-specific, as by it’s nature those products (SP and IDP) seem to obfuscate the logging process somewhat, and for the uninitiated, it can be quite daunting to determine what to long and where it’s controlled. This is further complicated, for example within SP on Windows, by how the Shibboleth Services interact with the web-browser of note. For example… if you’re leveraging Shibboleth SP on IIS, do you know what’s written to shibd.log vs. native.log. And importantly, do you know how to configure native logging properly to a file so that you don’t have to deal with Event Viewer?

It’s fundamentally important to understand what data you’re logging and have access to if you are tasked with providing SSO Support for your organization.

In SSO it’s quite rare that there are problems that result in no useful logging information. And when that does occur, 90% of the time it implies that the issue isn’t on your end, but on your integration partner’s end. The remaining 10% are usually the result of not having the correct logging categories enabled.

Being Proactive

A properly deployed environment will have at least some degree of monitoring involved. This doesn’t necessary mean deploying a full monitoring solution like Nagios, Graylog, or Splunk. More importantly, a simple audit of the logs on a normal cycle (weekly? monthly? when you can remember it?) is better than nothing.

Here, I find logging to files more useful, as you’ll be able to pretty quickly determine what’s an error that we should concern ourselves with – i.e. a particular metadata feed URL randomly dies – versus a warning we can safely ignore – i.e. a user hitting the back button at the wrong time resulting in a stale session warning.

Whatever your SSO environment looks like, take time to familiarize yourself with what is – and isn’t – logged:

• Shibboleth SP Logging
• Shibboleth IdP Logging
• SimpleSAMLphp Logging — unfortunately, documentation here is sparse. One line under Maintenance. (Look for a future post from us concerning the topic. Will update this post when available.)
• ADFS Logging

Next time… SSO Management Best Practices

We’ll dive into best practices for managing integrations in your environment… what information you should require, to sign or not to sign, and why a good documentation bundle can save you a TON of headaches.

† Or — how I learned to stop worrying and love XML.