The one way relationship between our user accounts and the MIS database also makes it difficult to engage with new users online. If you can’t get an account until you become a student, how do you allow potential students to apply online if all your systems are integrated with single sign-on? And if you can’t authenticate the online identity of your users, how do you set initial passwords into your system? Or allow them to reset a forgotten password online?

Internet companies never struggled with this issue, as their customers could only approach them online, but most universities built systems around paper applications and have fond (and relatively recent) memories of offering their students their first internet experience. It’s still not unusual for universities to offer their students their campus computing account with a default password based on supposedly secret data shared between the user and the school. But your SSN, birth date, and mother’s name are no longer secret. A proposed change in FERPA policy (see the the top of page 15586 in the NPRM) would have barred the use of “a common form user name (e.g., last name and first name initial) with date of birth or SSN, or a portion of the SSN, as an initial password to be changed upon first use of the system” in systems that store academic data. The final rule excluded that provision, much to the relief of those schools with more lobbying clout than brains.

Platform Choices

Rather than wait to see how the ruling played out last year, we went to work trying to improve security while easing access to our systems (no, that is not self-contradictory). Our challenges were thus:

• Fix initial password assignment
• Fix password resets
• Allow users with a loose or undefined relationship to the institution to create limited accounts for the purpose of interacting with the institution or its members

We considered a number of paths to a solution, including hacking of our university portal (which hosts the CAS single sign-on in our environment), expansion of a limited home-built solution, and a review of commercial and open source products and frameworks. We simplified the problem by confirming that the FERPA rule did not require us to authenticate the “real life” identity of a person; rather, we had only to validate the online identity of a person (saving us from needing to do things like send confirmation PINs by postal mail to a person’s home address).

In the end, we chose WordPress MU. Significant factors were our experience with the software (all the MIS developers use it personally), the extensibility of it as an application platform, the development focus on user experience (especially in recent versions), and our interest in using it as a framework for other user-facing services (especially BuddyPress).

Our Needs vs. WordPress

• The system must serve as the front end to our single sign-on environment, using our AD and LDAP password stores to authenticate users who have accounts in those systems.
• External email addresses, once verified with some challenge/response, can be used to reset a password.
• Users who are presently affiliated with the school have a school-provided email address, but no external address with which to reset their lost passwords.
• Users who are not presently affiliated with the school have no school-provided email address, and must verify their external email address before their account is activated. They can then set their own password once they verify their email address.
• The ability to send password reset codes via SMS would be nice (especially considering the number of long-time employees of the university who do not have personal email accounts), though that also requires the verification of the user’s cell phone number.

After reviewing what we wanted to do, we surveyed WordPress’ code to develop an implementation plan. And, because a number of aspects of our application process were changing, we decided to focus on allowing current users to self-reset their password and postpone development of account self-creation features for new users. Still, a few issues quickly emerged:

• WordPress requires a username be assigned to each user, rather than relying on email address (this is likely to change in WP 2.9) Creating a new username for our users is unacceptable, but adding a large number of new users to our existing username space will quickly deplete the “good” usernames. And changing a user’s username as their affiliation with the institution is unacceptable.
• The core user authentication function can be replaced with our own function. (And in 2.8 it became filterable)
• WordPress MU will validate email addresses, but the system isn’t built to be extensible.
• WordPress only stores one email address per user, but the user meta system can be used to store a second one. Unfortunately (and in a manner inconsistent with post meta), only one value per meta key per user is allowed, making it difficult to allow users to have an arbitrary number of email addresses associated with their account.
• The function that identifies a user by a given email address can be replaced with a function that also checks the secondary address.
• WordPress user profiles have no phone field, but the user meta system can be used to store one. A function to identify a user by a given phone number must also be created.
• Unlike some settings pages, the fields on the user profile editor cannot be changed simply by modifying the $wp_settings_fields array.
• Upon doing a password reset, the user is sent a temporary password, rather than being allowed to set a new password. This contradicts University policy about how passwords are used and communicated and could train users that sending passwords by mail is acceptable.
• The various functions in wp-login.php cannot be replaced, and in WP 2.7 the code had no way to add or replace various login actions (WP 2.8 changed that).
• WPMU-specific functions don’t always follow WP coding standards or models.

(Note that we began our work and deployed the system under WPMU 2.7. WPMU 2.8 included a few changes that made the process easier. I’m proud to say that some of those changes were a result of code we offered back to WP during our development.)

What We Did

• We decided that email addresses (both PSU addresses and external addresses), as well as PSU usernames would be acceptable identifiers for an account, and that a person should be able to log in to our web services using any of those identifiers. So…
• We replaced wp_autenticate() with our own function that accepts either email address or university username, checks to see if the user exists locally, checks to see if they exist in AD or LDAP, confirms their password, provisions their WordPress account (for university users who’ve not logged in via this method yet), establishes a session with our university portal and redirects them there (unless $redirect is set to something more specific that the dashboard).
• We decided to replace WordPress’ usernames with a random string matching a pattern we established. This became the WPID. Doing this required us to hide references to username (easy if you set a preferred display name)
• To store phone numbers and secondary email addresses, and allow users to edit those within their profile, I created the Alternate Contact Info plugin (browse source). This requires more use of output buffering than I’d like, but it gets the job done.
• To confirm email addresses and phone numbers via a challenge/response message (and support other interactions), I created the WordPress Ticket Framework plugin (my introduction, browse source).
• To send messages via SMS, we used my wpSMS plugin (in the plugin directory, browse source).
• Matther Batchelder re-skinned the login screen via a plugin that inserts our custom CSS.
• After determining that our university portal could not be made to authenticate via CAS, I gave up work on my wpCAS Server plugin and developed another method to initiate the portal session (which then establishes a CAS session using the portal’s CAS server).
• We replaced most of the functionality of the wp-login.php page (by hacking core at first, then taking advantage of the action hook in 2.8). In doing so we were able to change the password reset behavior to allow users to immediately change their password after entering their reset code (which was sent to their email address or phone via SMS).

Over time we extended the system to host multiple domains and replace our CMS. Soon we’ll consolidate our  public blogging instance into it, and we’re building an invite system that we can use to invite people to join our community.

What It Looks Like

The re-skinned WordPress login

Entering an email address or username to get a password reset code

SMS text with password reset code

Enter the password reset code from the SMS text message here, or follow the link from the email

Extended contact information in the WordPress profile

And that’s how we replaced our authentication system with WordPress, gained self-service password resets, and built the foundation to invite new users into our system.

WordPress MU is a solid CMS to support a large organization. Each individual blog has its own place in the organization’s URL scheme (www.site.org/blogname), and each blog can have its own administrators and other users. Groups of blogs in WPMU make up a “Site” and one or more Sites can be hosted with a single implementation. (I’m capitalizing Site for the same reason WordPress docs capitalize Page) Each Site has a defined set of administrators and options controlling various features. You might, for instance, lock down the plugins on your blogs.site.org, while keeping it open on your www.site.org. Or maybe you’d like to let your helpdesk staff create new blogs at blogs.site.org, but not at www.site.org. That’s what WPMU’s notion of Site can help you control.

Challenge: setting up service on multiple (sub-) domains

WordPress MU makes it easy to host both blogs.site.org and www.site.org within a single implementation, but there’s little documentation for how to do it.

Once you get WPMU up and running on one of your domains you can add another. The following assumes that you’re using the vhost=no setting (correct: I really mean vhost=no), that you have access to and know how to manipulate your MySQL, that you have control over your DNS and know how to use it, and that you know how to configure Apache or similar. You’d also be smart to turn off any object caching you may have running, at least until we’re done doing direct database manipulation.

Some might ask why I’m not simply using Donncha’s plugin, and the answer is simple: it only works for vhost=yes sites. For my own use, I find that sub-directories are easier for users to make sense of (go ahead, try to tell your mom to go to “myblog.sub.domain.org“).

Set up your web server

If you’re using Apache, you’ll either need to create an IP-based virtual host or manually configure your name-based virtual host for every (sub-)domain you plan to serve. Why: WordPress will handle the domain mapping for you, so it’s better to keep Apache out of the way and let WPMU own the entire IP.

Set up your DNS

Point each subdomain you plan to host in WordPress to your webserver. You can use a wildcard domain, but you don’t have to.

Create a new blog in WPMU

It doesn’t matter what you call it or what the path is, just create one. Now go edit it in the Site Admin:

Change the domain and path to match your new domain.

One quirk of WPMU is that it strips “www” from any domain name you enter (or is requested), so don’t bother trying to enter it (unless you’re willing to do some hacking to make it work). WPMU stores domain and path information in three locations: the wp_#_options table for the blog, the wp_blogs table, and the wp_sites table. When you edit a blog in the Site Admin, you’ll get a chance to edit the domain and path for both the wp_#_options and the wp_blogs tables. Clicking the helpful checkbox above will do most of that for you, but you’ll need to manually update the Upload Path.

Now make sure the new domain is shown in the blog's options as well.

You might be able to load the blog at the new URL as soon as you update those settings, but recent versions of WPMU set some constants in wp-config.php that can get in your way.

Reconfigure wp-config.php

Your wp-config.php might have something like this:

$base = '/';
define('DOMAIN_CURRENT_SITE', 'sub.site.org' );
define('PATH_CURRENT_SITE', '/' );
define('SITE_ID_CURRENT_SITE', 1);
define('BLOGID_CURRENT_SITE', '1' );

Those constants override the database checking that goes on in wpmu-settings.php to map the requested domain to a site. You have three choices: leave it as it is (and use only one “Site”), remove it and have WPMU do the mapping against the database, or expand the hard-coded mapping to include other sites.

I’ve used code like the following to do just that:

if( preg_match( '/(.+?\.)?([^\.]+?)\.site.org/i', 'www'. $_SERVER['SERVER_NAME'] , $matchedsubdomains ))
{
	switch( array_pop( $matchedsubdomains )){
		case 'connect':
			define('DOMAIN_CURRENT_SITE', 'blogs.site.org' );
			define('PATH_CURRENT_SITE', '/' );
			define('BLOGID_CURRENT_SITE', '1' );
			break;
		case 'www':
		default:
			define('DOMAIN_CURRENT_SITE', 'site.org' );
			define('PATH_CURRENT_SITE', '/' );
			define('BLOGID_CURRENT_SITE', '2' );
			break;
}
}
else
{
	define('DOMAIN_CURRENT_SITE', 'site.org' );
	define('PATH_CURRENT_SITE', '/' );
	define('BLOGID_CURRENT_SITE', '2' );
}

Set up your new Site

Once you have your new sub-domain working with one blog, you can create your new Site. Even if you don’t plan to create separate management policies for the different sites, it’s easier to create new blogs at each sub-domain if they each have their own Site.

Go in to your MySQL tool of choice and browse the wp_site table. There you’ll see just one row, but if you’ve made it this far you can also probably figure out how to create a new row representing the site at the new sub-domain. And once you do that, you can change the entry in the wp_blogs table to associate it with your new Site.

Set up the admins of the new site

Creating the new entry in wp_site doesn’t set the options for the new Site, and that means there are no Site administrators yet. Once again in your MySQL tool of choice, open up the wp_sitemeta table and look for an entry with meta_key = 'site_admins'. The meta_value for that entry is a serialized array containing WordPress usernames of the people who have site-wide administration privileges on the first Site. I’m assuming that if you have MySQL access you’re also a Site admin, so the easy thing to do is copy that row and change the site_id to match the auto-increment value from the new wp_site entry you made in the last step.

With the database manipulation done, you should now be able to go to the WP dashboard at your new Site, visit the WPMU admin options screen, and set the other options as necessary. You could decide to make one of your Sites open registration (remember, however, that users are shared across all Sites), while making other Sites more closed. And, obviously, you can delegate different Site admins for each Site.

Sub-domains or just different domains?

It’s worth noting that the instructions so far apply to both sub-domains and domains. You can use a single implementation of WPMU to manage content at both lolzors.org and tehsite.org. The detail about sub-domains really only applies to the next part. It’s also worth noting that you can support an arbitrary number of blogs, sites, and domains; I’m just using two sub-domains as an example.

Challenge: unified log in cookies

What’s the point of hosting multiple sub-domains with one WPMU implementation if you’ll need to log in separately at each one?

Set your cookie path

Setting a cookie path that that’s broad enough to cover the entire domain will solve this:

define('COOKIE_DOMAIN', 'site.org');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');

Avoid conflicts with other WordPress installations at your domain

But having such a broad cookie domain can interfere with other WordPress implementations. You’ll have to solve that by setting a unique cookiehash:

define( 'COOKIEHASH', 'asdf_arbitrary_string' );

You’d do better to keep it shorter than that, though.

Challenge: unified log in location/URL

WordPress MU is happy to handle authentication requests wherever it hosts a blog, but some organizations prefer to funnel all authentication requests through a single location. The idea is to provide some protection against fishing (assuming users can ever be taught to look at URLs) and make it easer to integrate external applications.

Filter login_url and logout_url

Set the log in and log out path to whatever you want, just make sure the destination knows how to create (or destroy) the WordPress cookies.

$hack_base_domain = 'site.org';

function hack_login_url( $path ){
	global $hack_base_domain;

	return preg_replace( '/^.+?\/wp-login.php/' , 'https://login.'. $hack_base_domain .'/wp-login.php', $path );
}
add_filter( 'login_url' , 'hack_login_url' , 10 );
add_filter( 'logout_url' , 'hack_login_url' , 10 );

Filter allowed_redirect_hosts

WP will normally block redirects outside the web root of the active blog, so you’ll need to tell it about your other sub-domains.

function hack_allowed_redirect_hosts( $allowed_domains ){
	global $hack_base_domain;

	$allowed_domains[] = $hack_base_domain;
	$allowed_domains[] = 'www.'. $hack_base_domain;
	$allowed_domains[] = 'blogs.'. $hack_base_domain;

	return $allowed_domains;
}
add_filter( 'allowed_redirect_hosts' , 'hack_allowed_redirect_hosts' , 10 );

I’m not really part of the Jasig CAS Community (learn more), but I do maintain the wpCAS WordPress CAS client and I’ve started development of a CAS server component for WordPress. That project is on hold because one of the products that I’d expected to integrate with it doesn’t use standard CAS and the vendor of that app has chosen to modify the JASIG CAS server to support their apps.

The standard is the protocol, not the server application, though we probably won’t really understand that until we see more CAS server implementations. Nonetheless, it’s important to keep that point in mind if we we hope to grow the usefulness of CAS.

I’m working to integrate an application on a remote-hosted IIS server into our CAS environment. CASisapi (svn trunk or svn tags/production) may do the trick, though Phil Sladen struggled with it (in 2005). There’s reason to doubt it. Not only is the sparse information all old, I first learned about it from a page full of broken links and the apparent author recommends against it. There’s a little more information here for those who can read Danish.

UC Davis’ CAS ISAPI client may be a better solution (it certainly looks easy to install). Builder AU talks about .NET + CAS, and Case Western has a lot of documentation. Only partially related: it looks like World of Warcraft uses CAS.

I said “identity management is the next big thing” back in September. That was before I’d seen Sxip founder Dick Hardt’s presentation on Identity 2.0. Zach peeped me the link and told me I wouldn’t regret watching the presentation. He was right. Everybody, especially the people who don’t yet care about identity management, should take a look.
authentication, authorization, dick hardt, identity, identity 2.0, identity 20, identity management, identity2.0, identity20, idm, sxip