Bug ID 602154: Multidomain SSO loses POST data because of HTTP 302

Last Modified: Sep 13, 2023

Affected Product(s):
BIG-IP APM(all modules)

Known Affected Versions:
11.5.3, 11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10

Fixed In:
13.0.0

Opened: Jun 29, 2016

Severity: 3-Major

Symptoms

In multidomain SSO, when accessing a virtual with a POST, the user may be redirected to the auth virtual. When the user is redirected back to the original url, we lose the original POST data. This is because we use HTTP 302, which allows the browser to change the method. In these situations we should use 307, which does not allow the browser to change the method.

Impact

User sends a GET to the resource, instead of the POST that should have been sent.

Conditions

This is difficult to avoid if the access policy needs to run on the auth virtual. This bug is about saving the POST when the policy has already run, and we are only redirecting to the auth virtual to receive the cookie.

Workaround

An iRule can be used to change some of the 302 redirects to a 307. when HTTP_REQUEST { set uri [HTTP::uri] } when HTTP_RESPONSE_RELEASE { if { [HTTP::status] contains "302" && ([HTTP::header value "Location"] contains "SSO_ORIG_URI" || $uri contains "SSO_ORIG_URI") } { HTTP::header replace ":S" "307 Temporary Redirect" } }

Fix Information

When redirecting to and from the auth virtual, we now use a 307. We continue using 302 with redirects to /my.policy and other parts of running the access policy. In those situations, a 307 could cause the browser to resend the POST made to an APM login page.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips