Doesn’t log user in after authentication

Resolved Paul Gilzow
(@gilzow)

7 years, 1 month ago
Will provide configuration information below.

Description of issue:
1. User clicks Sign In button beneath Use one-click authentication
2. User is taken to IdP and asked for credentials
3. User enters credentials, clicks login
4. User authenticates and returns to wp-login.php?action=wp-sam-auth
5. User clicks Sign In button beneath Use one-click authentication
6. User is taken back to IdP, but because they are already authed, is redirected back to site
7. User is taken to /wp-admin/
Expected behavior: Same as above except steps 5 and 6 are not included.

I’ve watched the SAML transaction with SAML Chrome panel and everything appears correct. Just can’t figure out why the user isn’t redirected back into /wp-admin/ once they get back to the login page.

Configuration data: https://gist.github.com/gilzow/fef89d3dd18bd0d28894cc58e33f1f2d
- This topic was modified 7 years, 1 month ago by Paul Gilzow. Reason: words

Viewing 8 replies - 1 through 8 (of 8 total)

Plugin Contributor Daniel Bachhuber
(@danielbachhuber)

7 years, 1 month ago
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?
Thread Starter Paul Gilzow
(@gilzow)

7 years, 1 month ago
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.
Plugin Contributor Daniel Bachhuber
(@danielbachhuber)

7 years, 1 month ago

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.
Thread Starter Paul Gilzow
(@gilzow)

7 years, 1 month ago
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 7 years, 1 month ago by Paul Gilzow. Reason: formatting
- This reply was modified 7 years, 1 month ago by Paul Gilzow. Reason: more formatting
Thread Starter Paul Gilzow
(@gilzow)

7 years, 1 month ago

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.
Thread Starter Paul Gilzow
(@gilzow)

7 years, 1 month ago
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 7 years, 1 month ago by Paul Gilzow.
Plugin Contributor Daniel Bachhuber
(@danielbachhuber)

7 years, 1 month ago

Sounds good, thanks @gilzow !

Thread Starter Paul Gilzow
(@gilzow)

7 years, 1 month ago

Pull requested submitted.

Viewing 8 replies - 1 through 8 (of 8 total)

The topic ‘Doesn’t log user in after authentication’ is closed to new replies.