JASchilz/wp-shib-pc-login.md

## wp-shib-pc-login.md

      
    Raw
  

              wp-shib-pc-login.md
            
          
    UWNetID WordPress Login @UW

Introduction

The basic flow of UWNetID WordPress login is:

Use an .htaccess file to "protect" the login/admin files, via PubCookie or Shibboleth.
User is directed to https://weblogin.washington.edu/ to authenticate.
When they return, their UWNetID is provided to Php through the $_SERVER["REMOTE_USER"] variable. A plugin checks this variable against the set of WordPress usernames and logs the end user in to a matching user.

Requirements

To use UWNetID login, you must:

Be able to create and edit files within your WordPress directory.
Be able to install a plugin.
Be on a UW-IT provided server. It may be possible to use UWNetID login if you're not on a UW-IT provided server, but you'll have to have server administration skills and permission to connect to UW-IT's authentication services.

Deficiencies, Dangers, and Mitigation

The WordPress plugins available for handling this process have not been updated in 2+ years. This introduces security concerns into authentication, which is a security-critical process.
To mitigate this risk, this guide UWNetID-whitelist protects all login and admin files: user access to login and admin are whitelist restricted at the web-server level. To my own satisfaction, this means that if the plugin we're using does introduce vulnerabilities, only those users in my whitelist will have an opportunity to exploit it.
This solution does preclude mixed login, in which some users authenticate via UWNetID and some users authenticate via traditional WordPress login: everyone must have a UWNetID to login. It must certainly be possible to implement mixed login securely, but this guide does not address that challenge.
Also note that because the relevant plugin is old and unmaintained, we have to implement a couple of work-arounds. Also, any new update to WordPress could potentially break the plugin.
Shibboleth vs. PubCookie

Shibboleth and PubCookie are two schemes for user authentication. If you are on a UW-IT managed server, then Apache probably has a module for one or the other installed. You probably do not have a choice as to which one to use.
For web development, either is invoked through .htaccess authentication. For example, protecting a directory under Shibboleth:
  AuthType Shibboleth
  ShibRequireSession On
  Require valid-user

Protecting a directory under PubCookie:
  AuthType UWNetID
  PubcookieAppID "My Application"
  Require valid-user

All of the examples below use Shibboleth, but to adapt the example to PubCookie, just replace any occurence of:
  AuthType Shibboleth
  ShibRequireSession On

with:
  AuthType UWNetID
  PubcookieAppID "My Application"

Both schemes are similar in that the user-id is subsequently provided to Php as the $_SERVER["REMOTE_USER"] variable. However, whereas PubCookie will identify a user as javerage, Shibboleth will identify the same user as javerage@washington.edu.
Initial Steps


Install WordPress


Create Initial User


Install HTTP Authentication Plugin


https://wordpress.org/plugins/http-authentication/


Make WordPress Login Trigger UWNetID Login

In your root WordPress directory .htaccess:
```
<Files "wp-login.php">
  AuthType Shibboleth
  ShibRequireSession On
  Require group my_osfa_admin_group
</Files>
```


Protect WordPress Admin

In your wp-admin .htaccess:
```
AuthType Shibboleth
ShibRequireSession On
Require group my_osfa_admin_group
```

Creating Additional Users - Non-Multisite

The HTTP-Authentication plugin attempts to override user creation, but is incompatible with recent versions of WordPress. In order to create a new user, you have to either:

Disable the HTTP Authentication Plugin
Create the New User
Re-enable the HTTP Authentication Plugin


or -

Enable Automatically Create Accounts in Settings->HTTP Authentication.
Direct the end-user to visit your wp-login.php page. This will cause HTTP Authentication to create a user for them, with an appropriate username.
Disable Automatically Create Accounts.
Go to user administration, find the created user, and give them the appropriate privileges.


If your login area is protected by a UWNetID whitelist, you may choose to leave Automatically Create Accounts enabled in order to avoid manual user account creation.
Notice that if disable HTTP-Authentication and then log out, you may have a difficult time logging back on: know the WordPress password for your account, or prepare another way of authenticating yourself.
Multisite Plus Shibboleth

For multi-sites, HTTP-Authentication does not override user creation. In fact multi-site plus PubCookie works seamlessly.
However, multi-site plus Shibboleth presents another problem: Shibboleth reports users as javerage@washington.edu, but WordPress only allows alpha-numerics in user names: WordPress will not allow us to create users of the form javerage@washington.edu.
To solve this issue, I had to modify wp-content/plugins/http-authentication/http-authentication.php around line 180 as follows:
$server_keys = $this->_get_server_keys();
    foreach ($server_keys as $server_key) {
            if (! empty($_SERVER[$server_key])) {
                    $username = $_SERVER[$server_key];
            }
    }

    // ADD THE FOLLOWING LINE:
    $username = strtok($username, "@");  // Strip the domain from the username

    if (! $username) {
            return new WP_Error('empty_username', '<strong>ERROR</strong>: No user found in server variables.');
    }

This strips the @washington.edu from javerage@washington.edu, meaning that we can create a user javerage with which Joe Average can administer our site.