Doesn’t log user in after authentication

Hi @gilzow,

Thanks for the report. I have a few questions to kick things off:

1. Just to confirm, you’re running the latest version of WP SAML Auth (v0.5.2)?
2. Is this a standard WordPress installation, or WordPress multisite?
3. Is this site hosted on Pantheon or elsewhere?
4. Have you tried using 'connection_type' => 'internal'? The SimpleSAMLphp integration is deprecated; using the bundled SAML library is preferred.
5. To rule out conflicts with other code, have you tried deactivating all other plugins and switching to the Twenty Nineteen theme?

1. Correct
2. Single site instance.
3. Elsewhere
4. Kind of stuck using SimpleSAMLPHP as that is what is required by our organization.
5. Yes. Single site, no plugins using twentyseventeen exhibits the same behavior as originally described.

Thanks for the update, @gilzow.

Pantheon only sponsors full support for sites hosted on Pantheon, or bugs with documented reproduction steps.

If you’d like 1-on-1 assistance debugging, feel free to reach out to the email address listed on my website.

I totally understand how difficult SAML/shibboleth issue can be to debug as I have to do so often. Not expecting anyone to fix this issue for me, but was hoping someone could point me in a direction on what to look for or where things might be going awry.

If I capture the SAML exchange, you can see that the RelayState is pointing back to the WordPress login url with a redirect_to parameter of /wp-login.php where I would think it should be pointed back to the admin_url (/wp-admin/).

https://shib-idp.umsystem.edu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=nVLLbtswEPwVgXeJtPySCduAGyOIgbQxLLeHXgpaXNUE%2BFC5y7b5%2B8pyiiQ9%2BNDTYoc7w9nBLlE528lNorM%2FwI8ESNlvZz3K4WHFUvQyKDQovXKAkhpZbz4%2ByrIQsouBQhMse0O5zVCIEMkEz7LddsW%2B6apS04mYnapqOoZqIab6pCezSk%2FK%2BUKVo5meNSM9bkXLsi8QsWeuWC%2FU0xET7DyS8tRDYrTIxTQX82MppKjkeP6VZdt%2BG%2BMVDawzUYeSczybU250VySHz0jgCtCJ9wDv12mNBX5xW%2FIDaBOhIV7XTyzb%2FDV%2BFzwmB7GG%2BNM08Pnw%2BCrtVGyCK5xBDCmaQRiN6yxckuEu6GSh6M4dH3q81jJXDQ6ohlYlSzl2LNu%2FZPvBeG3899uxnq5DKB%2BOx32%2Bf6qPbL28aMshprj%2Bf4cOSGlF6h%2BDS%2F5Wfnm9ok%2B9sd12H6xpnrP7EJ2i274viNF5O4xKisqjAU993NaGX3cRFMGKUUzA%2BPr65ftbXf8B&RelayState=https%3A%2F%2Fmarcom.missouri.edu%2Fwp-login.php%3Fredirect_to%3D%2Fwp-login.php%3Faction%3Dwp-saml-auth

so relaystate is domain.edu/wp-login.php&redirect_to=/wp-login.php&action=wp-saml-auth which doesnt seem right.

Any ideas on why it would set the redirect_to to /wp-login.php?

• This reply was modified 5 years, 6 months ago by Paul Gilzow. Reason: formatting
• This reply was modified 5 years, 6 months ago by Paul Gilzow. Reason: more formatting

ok, i think i figured it out. It all starts at line 269 in the class-wp-saml-auth.php file. You first grab the login url and set it to $redirect_to. this is normally something like domain.edu/wp-login.php. You then compare this to _SERVER[‘REQUEST_URI’]. Since at this point the wp-saml-auth action is attached, REQUEST_URI ends up being wp-login.php?action=wp-saml-auth. Therefore, the test at line 271 always fails and you set the redirect_to parameter to /wp-login.php?action=wp-saml-auth. The user auths at the idp and is passed back to wp-login.php but is now missing the action parameter because it is encoded into the redirect_to parameter. When the user hits the shib auth link again, now the action parameter is included, when they’re bounced back from the IdP, the action parameter is intact and your plugin can verify the shib session.

My suggestion is to extract the actual request from REQUEST_URI stripping out any query parameters before you compare at line 271. Then, add an else to that test and re-append your action before handing it to the provider->requireAuth method. I have it working on a test instance and can share if needed.

looking more into this today. Appears that you might have developed against a system using Apache, as its REQUEST_URI only includes the path component, and excludes the query string. However, we’re using nginx and nginx’s REQUEST_URI contains the full original request URI, with arguments. I don’t use IIS, but from the microsoft docs, it appears that IIS’ REQUEST_URI also includes the arguments from a request.

I’ll submit my changes as a PR over on github.

• This reply was modified 5 years, 6 months ago by Paul Gilzow.

Sounds good, thanks @gilzow !

Pull requested submitted.