WPIntell

Source evidence

Switch from Apache to NGINX environment

WP SAML Auth · support · 2024-04-16T09:07:00+00:00

mixedsentiment
highseverity
0.95relevance
3replies
Evidence linked to opportunitycommercial context

Proof Health

Open evidence

Commercial opportunities need traceable source links before they are treated as build-worthy.

5 / 25 rows with source links

20.0% of this page's analysis has direct source links.

0 build-decision rows missing links

0 rows here require auditable proof before promotion.

20 rows with no attached evidence

0 rows have source counts but still need direct links.

Conversation

support
nemseck resolved
I’ve used this plugin to successfully configure a connection between a private portal and an SSO service provided by a third party subject. Everything worked perfectly without flaws but due to a tech switch we moved from the apache-based environment to an nginx one. Then the plugin stopped working properly. These are the steps that lead to the error: [my site] click on a “authenticate” button [third party service site] insert username and password [my site] correct fallback to the declared page but the authentication goes wrong with this weird message: User is not authenticated with SAML IdP. Reason: The response was received at https://www.my-portal.example/my-login.php instead of https://www.my-portal.example/my-login.php Basically the system is telling me that the matching urls (for some reasons) are not matching! Is something related to NGINX port forwarding adjustments? Thanks The plugin definitely works on Nginx environments, so changing the webserver should not cause it to suddenly stop working. It’s likely an issue with the configuration. You might need to go through the setup/configuration process again (in fact, I would assume you would). My assumption is that the identity provider (IdP, your third party service) is configured to expect the request to look like the ones you’ve sent before (from the old server), but because the server has changed, it’s getting confused. In which case, you’d likely need to reset the IdP again for the new server. Thanks for your answer. In the meantime I’ve figured it out what was the problem. We’re using WP-Hide PRO in order to change all basic WP paths for security reasons and the issue was caused by a conflict between virtual host rules and WP-Hide rewrite rules. In particular the lines related to wp-login.php rewriting rules had to be declared at the very bottom of the virtual host configuration. Probably the priority of rewriting rules generated a mismatch in the response. That makes sense to me, glad you figured it out!

Comments

3 shown
Chris Reynolds 2024-04-18T16:10:00+00:00

The plugin definitely works on Nginx environments, so changing the webserver should not cause it to suddenly stop working. It’s likely an issue with the configuration. You might need to go through the setup/configuration process again (in fact, I would assume you would). My assumption is that the identity provider (IdP, your third party service) is configured to expect the request to look like the ones you’ve sent before (from the old server), but because the server has changed, it’s getting confused. In which case, you’d likely need to reset the IdP again for the new server.

nemseck 2024-04-19T06:30:00+00:00

Thanks for your answer. In the meantime I’ve figured it out what was the problem. We’re using WP-Hide PRO in order to change all basic WP paths for security reasons and the issue was caused by a conflict between virtual host rules and WP-Hide rewrite rules. In particular the lines related to wp-login.php rewriting rules had to be declared at the very bottom of the virtual host configuration. Probably the priority of rewriting rules generated a mismatch in the response.

Chris Reynolds 2024-04-19T14:29:00+00:00

That makes sense to me, glad you figured it out!