By the way, the WP_User object that is being passed back has the “administrator” role with a user_level of 10, so it’s not permissions (I don’t think).
I’ve been through that problem once
Have you checked that the .htaccess file does contain a
AuthType Shibboleth
Require Shibboleth
does shibboleth works fine one the same host for a sperate location (outside wordpress, /secure for example).
I also noticed that if you define attribute “mapping” for “user profile data” within shib plugin settings, beware that the attributes are not filtered out by the SP configuration.
For example, I my case , I had the eppn for mapping the username, and that attribute was filtered out by shibd attribute-filer.xml for certains users that had a domain name out of the scope of the metadata domain .
Then I suppose it was impossible to create (or match) the user from shib to local WP users, then it looped back to the wp-login.php .
jasonrhodes –
I didn’t see this one earlier. We (USC) ran into the same problem – Shibboleth wasn’t working with WP multisite. Did you figure it out?
We did, but I forget the exact details. The main problem is that the Shibboleth plugin was not meant to work with WP multi-site (sub domains). If all blogs were on a single server, then the Shibboleth plugin worked great. The second issue is when logging into any site(any other than the default/main site), WP would delete some of the authentication cookies. That second issue is probably what you are seeing – a valid Shib auth redirects back to wp-login.php.
The solution would be to modify WP core file(s) and update the Shibboleth plugin to handle multiple subdomains. Unfortunately we decided that this was too much work and decided to drop Shibboleth support on WP.
Did anyone ever have any luck getting this to work in Multi-site with sub-domain installs? I have been wrestling with this, and other issues in our test 3.2 upgrades. I’ve emailed the developers and they might be able to help. If they do I’ll post something here.
One additional hurdle that I had to overcome was an obscure Apache problem that caused the “AuthType shibboleth” directive in my .htaccess to be ignored, because (in effect) the relevant parts of Apache processing have to happen before the .htaccess file can be located. The solution was to move the “AuthType shibboleth” directive from my .htaccess file to a corresponding <Directory> or <Location> block in the main Apache configuration file (which used “AuthType Ucam-WebAuth” for other parts of the server). Maybe that insight helps someone here as well?
My organization bumped into the problem of this plugin not working correctly with a multisite install. So, I implemented a set of changes to add support. See this article on WordPress multisite + Shibboleth for details and a download.
