Apache 2.4 Require All Granted Problem

Symptoms

We usually see this problem on WordPress sites that are using a Shibboleth login module like the NCSU Mars plugin and are also using a security plugin like iThemes Security Pro that attempts to block bad clients by their IP address. This only affects sites on Apache 2.4 or newer.

When a user tries to login to an affected site, they are sent to Shibboleth to provide their credentials. Upon successful login, the IdP tries to send them back to the WordPress site and gets stuck in a loop. If you watch the URL bar of the browser, you may notice the page is repeatedly retrying the login with slightly different URLs each time.

Details of the Problem

This is what's going on in the code:

user requests a login, WordPress sends them to the IdP
user logs in, IdP sends user back to WordPress
WordPress plugin looks for user's attributes from Shibboleth and does not see them
plugin returns the user to the login page to login
IdP remembers the current session and sends the user back
WordPress plugin looks for user's attributes from Shibboleth and does not see them
... repeat until the browser gives up ...

The question is: Why does Apache fail to pass the Shibboleth attributes to the login page when the user has a valid session?

The answer is: The newer Apache 2.4 authorization rules assume that any matching rule should be allowed for a session, unless you explicitly tell it to check all the rules.

Here's the Lazy Sessions shibboleth rule that is used by the auth plugins for WordPress:

AuthType shibboleth
ShibRequestSetting requireSession false
Require shibboleth

By itself in an .htaccess file, that rule will work fine. If the user is logged in to Shibboleth, then Apache will pass the Shibboleth attributes to the plugin.

Here's a rule created by iThemes Security Pro, which is supposed to block access to the given IP address.

<RequireAll>
  Require all granted
  Require not env DenyAccess
  Require not ip 192.168.199.199
</RequireAll>

This also works correctly on its own. When both rules appear in the same .htaccess file, Apache will accept the "Require all granted" rule first, and will not evaluate the "AuthType shibboleth" section at all. The order that they appear in the file does not seem to matter. In either case, a user not from that IP address will be allowed into the site and the Shibboleth attributes will not be evaluated or passed.

General Fixes

There are two ways we can fix this (temporarily) in the .htaccess file. The "Require all granted" line seems to be the key to the problem. The first solution is to comment out those lines, so Apache will evaluate Shibboleth correctly. Be sure to get all of the lines if the plugin has created more than one of these sections.

<RequireAll>
  # Require all granted
  Require not env DenyAccess
  Require not ip 192.168.199.199
</RequireAll>

AuthType shibboleth
ShibRequestSetting requireSession false
Require shibboleth

Since the iThemes Security plugin is likely to update the .htaccess code again, it will eventually undo this fix.

The second, possibly more permanent fix is we can wrap the whole thing in a RequireAll block. That will tell Apache it must require All rules that it finds, and it will correctly pass the Shibboleth attributes.

<RequireAll>
  <RequireAll>
    Require all granted
    Require not env DenyAccess
    Require not ip 192.168.199.199
  </RequireAll>

  AuthType shibboleth
  ShibRequestSetting requireSession false
  Require shibboleth
</RequireAll>

This will work so long as the plugin updating the IP access rules does not try to add new rules outside of the RequireAll block that we created.

Fixes for iThemes Security Pro

After being alerted to this issue, iThemes customer support determined that the best course of action would be to disable automated user banning functionality, including the "Banned Users" option and the built- in "quick ban" feature. This does not affect the other ways that iThemes Security protects and hardens WordPress.

To disable the "Banned Users" feature: In the iThemes Security settings (Dashboard > Security > Settings), find the section labeled "Banned Users." Click "Disable" to disable feature.

To disable the "Quick Ban" feature: iThemes customer support has provided code to disable this feature, which OIT has packaged as a plugin.

If your WordPress website has the campus Cthulhu plugin installed (recommended, in case there are future updates)
1. In your Cthulhu settings (Dashboard > Settings > Cthulhu Settings), make sure the OIT plugin repository is active. If it is not, you can add the OIT repository with the URL https://www.webtools.ncsu.edu/wp-updates/pkg/oit . No access key is required.
2. Go to Dashboard > Plugins > Add Plugin, and search for "OIT Disable iThemes Quick Ban"
3. Install and activate the plugin
If your WordPress website does not have the campus Cthulhu plugin installed, you can download the plugin from GitHub. (authentication required)

Disabling both of these features as described above should resolve any iThemes Security conflicts with Shibboleth.