
This guy’s official.
cc licensed http://www.flickr.com/photos/dkscully/5038201085/
I just completed a major overhaul of the authentication process by which users log in to Blogs@Baruch. Previously, users were able to create accounts on the system as long as they had a Baruch email address. Just over a year ago, however, our CIO requested that we implement Active Directory authentication, and we’ve been working towards this for some time. Now, any user in the college’s Active Directory can simply log into the system, and doing so creates their account.
Several technical issues needed to resolved before we could make the switch. The two biggest were the inadequacy for our purposes of existing ad integration plugins and the process by which existing local WordPress users would be migrated to AD accounts. I worked with my friend Boone Gorges to address these issues, using Glatze’s Active Directory Integration plugin as the base. We had considered using Curtis Grymala’s fork of Glatze’s plugin, and Curtis was very generous in taking the time to explain his modifications to us, but ultimately we concluded Glatze’s plugin seemed to get us closer to where we needed to get.
Boone ultimately wrote a plugin called BLSCI-AD (get it on git) which combines all of the specific functions that we needed for this project. It fixed some problems Glatze’s plugin had working with WordPress multisite, addresses some fallback account assurances we needed (users who were not successfully migrated to AD — about 8% of our 10k+ users — are still able to log into the system using their old credentials), and, most importantly, runs a check of all existing users against the email addresses present in AD. When it finds a match, if the WordPress username and AD username aren’t the same, it changes the user’s WordPress username to the one in AD. While the migration is being performed a record is generated, sortable by successes, failures, and with additional data like user creation date, migration attempted date, and last activity date. The usernames of those whose migrations fail are manually editable through the report page, and every user’s previous ID remains recoverable.
This is really a remarkable bit of code, not least because of the hilarious and helpful PHP comments Boone strews throughout. There’s a lot of justifiable love for Boone on the web, but personally I enjoy working with him because he appreciates the complicated contexts in which we work, gets and supports the mission of our project, and approaches each contract as a collaborative puzzle–solving experience. Thanks, Boone!
I did have some mixed feelings about this transition, and I’ve been struggling to put them into some sort of order over the past few days. Blogs@Baruch began as an independent experiment, resistant to centralization and institutional oversight, and hostile to any outside efforts to control. But as we’ve grown and responded to community need certain pressures have been put upon us: all incoming freshmen do work on our system, and several programs, centers, and projects use us for their web presence. The college sees this as a space worth supporting and building along the trajectory we’ve already established. One goal they’ve had which over time came to implicate us was to simplify access to and unify logins for the various services the college offers. We had some concerns about this as an effort to establish control over Blogs@Baruch, but were satisfied through conversations with BCTC that this wasn’t the case. Tom Harbison (who along with Craig Stone helped us through the migration tremendously) and I have been granted the administrative rights to create Active Directory users. We’ve also been assured that all users who have had access to Blogs@Baruch in the past will continue to have access into the future regardless of their current relationship with the school. These are meaningful choices, especially in a place like CUNY.
So, while I’m a bit skittish about the implications of centralization (and a touch nervous about the performance implications of SSL admin rule now in place), I’m tremendously pleased about this technical accomplishment, and also about its impact on user management. Any user who is currently active in Baruch’s Active Directory can now simply log in to Blogs@Baruch with the same account they use to log into the wifi and into the school’s computers. If they had an account, all their stuff is there; if they didn’t, a user is silently created for them against their AD profile (it feels as though the user already existed).
I know that there’s some resistance to the fetishization of single sign-on out there in the hipster web, and I certainly am sympathetic to those arguments. If the experience is meaningful enough, folks will log in however they can to get it. We have a lot of that on Blogs@Baruch. But we also have users who are completely new to such experiences, who might be resistant for reasons cultural or philosophical, or who have been compelled to use the system by a faculty member. Those users now have zero technical barriers to entering the system, and I’m curious about what kind of serendipity that just might lead to.
A couple other technical notes. We use Boone’s Simple Import Users plugin to allow faculty members to easily bulk add users to individual sites. As part of this project, he wrote an AD check into that plugin so that if users haven’t been created in WordPress yet when their email addresses are entered into the import users field, an account is created for them. I hacked that plugin a bit to change the defaults and simplify the email generation options.
I also wrote a function into our BuddyPress theme to pull in the user’s Active Directory Description:
function DisplayedUserDescription() {
$user_meta = get_userdata(bp_displayed_user_id());
echo '
<div class="bp-widget">' . '
' . '' . 'Active Directory Description: ' . '' . '' . $user_meta->description. '' . '
' . '</div>
';
}
add_action( 'bp_after_profile_field_content', 'DisplayedUserDescription' );
And, finally, I hacked together a file (placed in mu-plugins) that changed the login page across the installation:
/*
Plugin Name: Login Hacks
Plugin URI:
Description:
Author: Luke Waltzer
Version: 1.0.0
Author URI:
*/
//Change Wrong Password Error Text
add_filter('login_errors',
create_function('$no_login_error',
"return '
You now must log in to Blogs@Baruch with your Baruch user name.
If you do not remember your password, please follow the reset link below.
';"));
//Change Login Field Names Text
function wp_field_names_change($translated_text, $text, $domain){
switch ($text) {
case 'Username':
return 'Baruch Username';
break;
}
switch ($text) {
case 'Password':
return 'Baruch Password';
break;
}
return $translated_text;
}
add_filter('gettext', 'wp_field_names_change', 1, 3 );
//Remove Register link
function remove_register_text ( $text ) {
if ($text == 'Register'){$text = '' ;}
return $text;
}
add_filter( 'gettext', 'remove_register_text' );
//Change Reset Password Link Below Login Form
function remove_lostpassword_text ( $text ) {
if ($text == 'Lost your password?'){$text = '
<h3 style="text-align: center;"><a href="https://mypassword.baruch.cuny.edu/" target="_blank">Reset Your Baruch College Password</a>
You now must log into Blogs@Baruch with your Baruch username.
All previous users of Blogs@Baruch will still be able to access their accounts after they are no longer affiliated with the school. We may however need to assist you in creating a new account and affiliating all content you previously produced with that new account.
If you are unable to log in, please email us at <a href="mailto:blsciblogs@baruch.cuny.edu">blsciblogs@baruch.cuny.edu</a> for assistance.</h3>
' ;}
return $text;
}
add_filter( 'gettext', 'remove_lostpassword_text' );
}













