Following a few questions around how and why we’ve set up our SAML2 (Shibboleth and other) infrastructure I thought I’d write a proper post about how we do various forms of Identity Federation in the SAML2 world.

History

A brief note on history… we started down the Shibboleth path with no prior knowledge back on Shibboleth 1 IdP on a pair of Solaris hosts in a primary–failover model (using LVS). This allowed us to have mock-high-availability without needing to understand or handle any state sharing between nodes – users caught in the middle of an authentication hop during a failover would see an error but running the process again should complete successfully. Our usage wasn’t high so this was deemed good enough.

Authentication was handled by our then central Single Sign On system in the form of Sun Access Manager and then Sun OpenSSO (using the Apache level agent and pushing REMOTE_USER into Tomcat). We also started rolling out SSO to other key systems.

Replacing OpenSSO with SimpleSAMLphp

A few years ago we decided to move from the very feature rich and complicated OpenSSO platform to the simpler SimpleSAMLphp platform to provide our core IdP functionality. This meant that we could no longer use the SunOracle provided agent to hand-off the authn and provide seamless single sign on across our existing estate and needed another solution.

We opted, at the time, for mod_auth_memcookie over mod_mellon as it was, again, simpler and, given we were using it on Solaris, was a lot easier to get working (mod_mellon required a load of SAML libraries where mod_auth_memcookie just handed it off to PHP to deal with).

Over time we have retired our Solaris IdPs and moved them to RHEL but have retained the primary-failover model using mod_auth_memcookie to keep the user experience seamless.

SimpleSAMLphp+mod_auth_memcookie served us well.

Office365 rollout

When approaching our upgrade from Live@EDU to Office365, at which time we’d become responsible for the authentication of users rather than replicating passwords up to the Microsoft Cloud and letting them do it all, we opted for Shibboleth over ADFS to carry out this function as we understood it and trusted it more than a piece of software we knew nothing about.

Not knowing entirely how much load our ~22,000 active users would put on our local infrastructure, we opted to build two new properly load balanced (and therefore easily scaled out) IdPs to handle the Office365 traffic but also wanted to maintain our seamless SSO so needed them tied into the central SimpleSAMLphp IdP, too.

Initially we were going to retain the mod_auth_memcookie+SimpleSAMLphp+memcached model but, during testing, it quickly became apparent that Microsoft were using the SAML2 POST profile which isn’t supported by mod_auth_memcookie. Fortunately for us, mod_mellon does! 🙂

Moving to mod_mellon had the unexpected benefit of removing the need for PHP or memcached to be running on our IdPs and, thankfully, the Office365 SP talks pure SAML2 and so doesn’t need any state preservation for Artefact resolution (as it’s all done via the browser) – so we didn’t need to share state between our N (currently 2) IdPs.

 Summary

We keep a local clustered Identity Provider running SimpleSAMLphp (and memcached) as our standard way of federating locally.

This central IdP functions as the upstream SAML2 service for our two load balanced, outward facing Shibboleth based Identity Providers – one for UK Access Management Federation and one for Office365 and using mod_auth_memcookie and mod_mellon respectively.