Our campus, like many others around the US, is part of the InCommon federation, and shares a federated SAML authentication pool. So, while IT services had straightforward documentation for how to plug Shibboleth into Apache2 to protect a “regular” website, it was very unclear how to connect that with Discourse.
After banging our heads against it for awhile, the clear (and now obvious) solution was to create a separate SSO endpoint that is Shibboleth-protected, and point Discourse to that using the built-in SSO provider.
Instructions for SSO are here.
A few details:
- The SSO endpoint we created is a single page of PHP, in a directory that requires Shibboleth authentication. Since our Discourse app is to be available to the entire university, any scoping is done at our IdP provider and not on our end.
- It parses the payload and signature in the query string to verify, unpack, and get the
nonce. - Then gets a few bits about the user via
$_SERVER['value']values (uid, eppn, sn, givenname) to create the new payload. - It then reassembles a new payload, with
nonce, encodes it and generates a new hash, then HTTP GETs the user back to the right endpoint on our Discourse site. - The only hangup was that I was generating the HMAC-SHA256 signature on the urlencoded payload and not the base64 payload. Once I saw that mistake and signed the latter, it worked perfectly.
You could do this in PHP, Python, Ruby, anything that can run simply in a web environment that Shibboleth plays nicely with.
The Discourse team did a good job on this feature – I like that you can pass basic bits of user data to the SSO and a new account is stubbed out without any fuss.