The WordPress Shibboleth plugin advertises WPMU support but does not seem to work with a WP 3.x Multisite/Network installation. Below is a patch to version 1.4 of the Shibboleth plugin and basic setup details needed to support sitewide Shibboleth authentication.
Before we begin, I assume you’re already familiar with installing and configuring Shibboleth, WordPress, and the WordPress Shibboleth plugin. If you haven’t already set up WordPress or a Shibboleth SP, either bribe someone who has or find a carafe of coffee and come back in a day or two.
What’s in the patch?
- Support for WP Multisite/Network with subdomains. I didn’t try this with a subdirectory implementation and don’t expect it to work.
- A setting to specify the common email domain for users’ email addresses as a combination of their shibboleth username + “@” + the common email domain
- Fixes for localization/gettext support.
- HTML markup fixes on the admin control panel page
Applying the changes
For Unix/Linux, just use the patch tool. Download and unpack the WordPress Shibboleth plugin zip file. Download the patch file, unzip it, and move it into the plugin code directory. `cd` into the directory. Apply the patch:
$ patch -p1 < wp-shibboleth-1.4-multisite.patch
According to Google, there’s an equivalent patch tool for Windows.
The key to making WP Multisite subdomains and Shibboleth happy is appropriate cookie scope. The SP must be configured to generate valid cookies for all subdomains on a site, but the default configuration in shibboleth2.xml results in host-scope cookies. You can change the cookie behavior via the cookieProps attribute of the Sessions element in shibboleth2.xml. This is a documented but not well-publicized feature. See the NativeSPSessions section of the Shibboleth documentation.
Edit the shibboleth2.xml file of the Shibboleth SP on your web server. Add the cookieProps attribute to the end of the Sessions element.
<Sessions lifetime="28800" timeout="3600" checkAddress="false"
cookieProps="; domain=.multisite.example.org; path=/">
Note the dot before the hostname. Also, be sure to include everything in double quotes above, or you may end up with an invalid cookie properties string in the http response from the SP. Restart shibd on the web server and clear your browser cookies after completing the changes.
You must register the Shibboleth SP with the IdP as the main WordPress site hostname (e.g. multisite.example.org). The Shibboleth IdP will only authenticate requests that come from the registered SP hostname. The WordPress application handles post-authentication redirects to send users to the originating site in the multisite install.
- The earliest version I tested was WordPress 3.2. It almost certainly won’t work with WPMU and may even break with WP 3.0-3.1.
- The common email domain option depends on getting the shibboleth SP and WP plugin settings lined up correctly. The shibboleth SP field representing the username portion of an email address must be mapped to the username field in the shibboleth plugin settings.
If you experience endless redirect loops, the cookie settings are probably not correct. Looping in this case means the browser bounces from the WordPress site (Shibboleth SP) to the Shibboleth IdP ad infinitum. You can check cookie data in Firefox with Firebug, a must-have for any sort of Web development. It’s also possible your browser has old cookies lingering about. If you continue to have problems, try clearing the browser cache, deleting all cookies, and restarting the browser. Sometimes closing a tab isn’t enough.
Shibboleth IdP errors or SAML assertion failures can occur if the SP is not correctly registered with the IdP, more specifically if the hostnames/URLs don’t match.
* photograph by jess g.