michaelryanmcneill / shibboleth

Shibboleth plugin for WordPress
https://wordpress.org/plugins/shibboleth/
19 stars 11 forks source link

Redirect Loop on Login attempt #34

Closed nilshoell closed 6 years ago

nilshoell commented 6 years ago

I have a problem setting up shibboleth-authentication for a wordpress-installation (both the wordpress-instance and the shibboleth-idp/sp are completely new set-up). The login at the service provider works as it should, I already configured the Login-URL and the redirect to the Shibboleth-Login-Page (example.com/Shibboleth.sso/Login) is working fine, I can log in and retrieve all attributes I defined. As soon as I try to log into WordPress, the URL (https://example.com/idp/profile/SAML2/Redirect/SSO?SAMLRequest=abcde...) is refreshing once a second endlessly, each time having a new Request-ID. In my webserver-logs, I can see that the endless redirect loop consists of "/wp/wp-login.php?action=shibboleth" -> "/Shibboleth.sso/Login?target=wordpress" -> "/idp/profile/SAML2/Redirect/SSO?SAMLRequest=..." and back to wp-login. I already added debug logs to the shibboleth.php logging the entire content of my $_SERVERS-Array during the execution of shibboleth.php, but there is absolutely nothing shibboleth-related, neither before nor after the login. A valid Session is created (as shown in /Shibbolrth.sso/Session), but not Accepted by the Plugin. I tried switching from the .htaccess-based protection to an Apache config, this of course protected the whole website instead the admin-folder only, but at least the sessions got accepted, and new users were created. The Login-loop hower was still there, but I could access WordPress when I reloded it.

jrchamp commented 6 years ago

Is the AuthType shibboleth block somewhere in there? Try adding a typo to see if the configuration file is being processed.

christianhauff commented 6 years ago

I am working together with @nilssiegle. When installing the plugin, it successfully added the two lines AuthType shibboleth and require shibboleth to the htaccess. The htaccess should be active, as we defined AllowOverride All in the apache-config (also tried to add the two lines directly to the Location-Block in apache-config, no effect) We can see that the apache config (vhost-file) is active, as if we add a require valid-user to it, we get redirected to the shibboleth-login as soon as we visit the wordpress-startpage (which is less useful). But as nilssiegle said, then, at least, the shibboleth-values appear in the $_SERVER-Array.

EDIT: Okay, that was a bit dumb! We thaught, the <Location "/wordpress">-Block including AllowOverride All would be doing it's job (because in the same vhost-config-file, we are using the exact same Location-Block for another folder which is working fine with the relative path), but i just tried adding mistakes to the htaccess and didn't get a Error 500. So I changed the Location-Block to a Directory-Block with absolute path to the wordpress-folder inside the documentroot and suddenly, the login worked! I'm still confused why

        <Location "/wp">
                AllowOverride All
        </Location>

has no effect while

        <Location "/shibbolethtest">
                AllowOverride All
                AuthType shibboleth
                ShibRequestSetting requireSession 1
                Require valid-user
        </Location>

works absolutely fine (same vhost-config, same document root). (the second block has also worked with putting the last 3 lines inside the htaccess)

nilshoell commented 6 years ago

It was too late yestrerday -.- Still wierd that the .htacess file itself was not enough, but it works.

michaelryanmcneill commented 6 years ago

As you discovered, AllowOverride can only be used within the directory context, it cannot be used within a location context. For more information, see this Apache doc: https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride. Thanks for the help @jrchamp!