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.<\/p>\n
A brief note on history\u2026 we started down the Shibboleth path with no prior knowledge back on Shibboleth 1 IdP on a pair of Solaris hosts in a\u00a0primary<\/em>–failover<\/em> model (using LVS<\/a>). This allowed us to have mock-high-availability without needing to understand or handle any state sharing between nodes \u2013 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\u00a0good enough<\/em>.<\/p>\n Authentication was handled by our then central Single Sign On system in the form of Sun Access Manager and then Sun OpenSSO<\/a> (using the Apache level agent and pushing REMOTE_USER into Tomcat). We also started rolling out\u00a0SSO<\/em> to other key systems.<\/p>\n A few years ago we decided to move from the very feature rich and complicated OpenSSO platform to the simpler SimpleSAMLphp<\/a> platform to provide our core IdP functionality. This meant that we could no longer use the We opted, at the time, for mod_auth_memcookie<\/a> over mod_mellon<\/a> 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).<\/p>\n 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\u00a0experience\u00a0seamless.<\/p>\n SimpleSAMLphp+mod_auth_memcookie served us well.<\/p>\n When approaching our\u00a0upgrade<\/em>\u00a0from 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.<\/p>\n 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.<\/p>\n 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! \ud83d\ude42<\/p>\n 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) \u2013 so we didn’t need to share state between our N (currently 2) IdPs.<\/p>\n We keep a local clustered Identity Provider running SimpleSAMLphp (and memcached) as our standard<\/em> way of federating locally.<\/p>\n This central IdP functions as the\u00a0upstream<\/em>\u00a0SAML2 service for our two load balanced, outward facing Shibboleth based Identity Providers \u2013 one for UK Access Management Federation and one for Office365 and using mod_auth_memcookie and mod_mellon respectively.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":"Replacing OpenSSO with SimpleSAMLphp<\/h1>\n
Sun<\/del>Oracle provided agent to hand-off the authn and provide seamless single sign on across our existing estate and needed another solution.<\/p>\nOffice365 rollout<\/h1>\n
\u00a0Summary<\/h1>\n