Integrating SSO for OERxDomains21

I have a love/hate affair with SAML and SSO in general. Damn, two acronyms in the first sentence?! Nothing like that to thin out the crowds. Still with me? Ok let's go.

The problem: While much of the conference we recently put on would be open (registration, main website, program, etc etc) the actual delivery space (a cool HTML-driven site with video player) needed to be behind a login to registrants. When I first dove into SSO options I relied a lot on WordPress and various plugins to make it happen (sort of in the same way I relied on WP and various plugins for any development work, baggage I'm still carrying in some capacity). But this site would be fully built in good ole HTML, CSS, and Javascript to be performant and fast.

ALT had some prior work here we could build on in that they had an IdP using Drupal as the authentication source for all conferences they run. To back up a bit when you're building in SSO via SAML (Security Assertion Markup Language) you have two players, a service provider (SP) and an identity provider (IdP). The SP is the app you have that you need to add a login to and you don't want people to have yet another login to your site. The IdP is the source of where people have accounts. So you've seen sites that have a "Login with Google" style button. Google is acting as the IdP in that scenario so you can login to whatever site you're on without having to create a separate set of credentials. So for this project we'd be using ALT's website as the IdP and having to build our own SP.

Even though the site was not going to use a scripting language I kind of needed a little bit of PHP here. There are ways around it by installing listeners on the server and getting fancy with Apache authorization methods, but given the server we were on would handle PHP I decided to just use that for the auth piece. There is a great project called SimpleSAMLphp that I downloaded and configured. You run it in a separate directory from the site you are protecting, configure it to work with the IdP you are using, and then you add some extra code to your site to protect pages. It can actually even act as its own IdP if needed but in this case I was just using it for the SP functionality and they have a great quickstart guide here https://simplesamlphp.org/docs/stable/simplesamlphp-sp.

Another important thing to note is that whatever IdP you setup needs to in turn also be configured to work with your SP. It's a handshake and I can't just decide "I'm going to have ALT's website users login to my site" without consent from ALT's website. So there's a small amount of configuration also necessary on the IdP side to give permission to specific SPs. ALT uses SimpleSAMLphp as well so that was straightforward by editing a single file to add the URLs for the new site.

I'm glazing over some of the finer points because this post isn't really meant to be a step by step tutorial but rather a reflection on how I accomplished this task. Once both sides are setup and configured to talk to each other, the only thing left is to actually protect a page. That's done with a small amount of PHP which initiates the authentication process before page load:

require_once('../../lib/_autoload.php');
$as = new \SimpleSAML\Auth\Simple('default-sp');
$as->requireAuth();

It loads in the SimpleSAMLphp code and then sets up a new authenticator using our default SP we setup and then requires authentication to continue. Put this at the top of your page and Bob's your uncle. The other handy thing you can do with SAML but I didn't utilize for this project is you can get attributes back from the IdP like first and last name or email address. A lot of sites use that so when you authenticate with an external source it can create a user profile for you and fill in some of the information automatically to personalize the experience. For this we just needed to make sure if someone was on a video player that they were authenticated and the nice thing is as long as you are storing cookies in your browser as most are you only need to authenticate once and it will last for several days, certainly long enough for a 2 day conference to not continually nag a login again and again.

Once the conference was over removing authentication to make it publicly available was as easy as deleting 3 lines of code at the top of the page.

Some ideas for people wanting to explore stuff like this would be if you are a G Suite org you can set that up as an IdP and then integrate with other sites. So Reclaim Hosting uses G Suite (or is it Google Workspace now? Whatever) and I built a WordPress site that used our reclaimhosting.com accounts to access it. The more you build in methods like this the easier access management on the whole becomes, because when someone moves on from your group you don't have to go remove a bunch of logins and you also don't have to share logins, all of that is managed centrally. This is the kind of stuff IT departments love but no one else tends to care about, but it's quite useful!

So there you have it, a small portion of an overwhelmingly well-coordinated fully online conference put on by the ALT and Reclaim Hosting team this year and it was fun to be of some use for the event :).