Troubleshooting: SP-Initiated POST Data Lost on IIS 403 Redirect

Version Affected: All
 
 

Overview

When a Service Provider (SP)-initiated request using HTTP POST is redirected — for example, by an IIS IP Address Restriction rule returning a 403 error redirect — the original POST data is lost, and the error "Failed to receive authentication request by HTTP POST" is shown.

 

Cause

SP-initiated by POST means the application sends its initial SAML request to SecureAuth in an HTTP POST body, rather than in the URL (an SP-initiated request sent in the URL is visible in the browser's address bar). When an IIS 403 error page redirects the browser to another realm, it is not able to preserve the POST data from the original request — the redirect happens, but the POST data is dropped.

To resolve this:

1. Open IIS Manager and select the realm where the 403 redirect rule is configured.
2. Open URL Rewrite and edit the existing IP Address Restriction rule that performs the redirect (or create a new blank rule if one does not already exist, matching on the {REMOTE_ADDR} condition).
3. Under the rule's Action, set Redirect type to Temporary (307), rather than the default Permanent (301) or Found (302).
4. Click Apply.

A 307 redirect instructs the browser to resend the original request method and body to the new location, which preserves the POST data between realms. 301 and 302 redirects do not guarantee this, which is why the POST data is lost with the default redirect type.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.