Forum Discussion
NimbostratusAPM redirect to /my.policy stripping POST data
I have a condition where an unauthenticated user sends a POST request to a F5 virtual server running Access Policy. As part of the authentication process, the F5 redirects the original POST to /my.policy which, in turn, responds with HTML that contains a
8 Replies
tjpSome of the question was truncated. The question was: I have a condition where an unauthenticated user sends a POST request to a F5 virtual server running Access Policy. As part of the authentication process, the F5 redirects the original POST to /my.policy which, in turn, responds with HTML that contains a HTML form that gets automatically submitted requesting the original content. This time without the POST data! Has anyone encountered this?
Max_Q_factorCirrocumulus
That is a feature. Lots of people have issues like that with SAML and APM.
Andy_TurnerI have this exact same issue with our Shibboleth IdP. The SAMLRequest is in the POST data section of the HTTP request prior to redirect and log in to APM. After log in to APM, it's gone. Users who already have an APM session prior to visiting the SAML protected site get in fine since the POST data is never stripped. Has anyone managed to fix this or found a workaround that still uses the POST data e.g. capturing it pre APM page and injecting it back in afterwards? I've just raised a support call anyway to try and get a resolution.- THi
When an unauthenticated user is requesting a page protected by APM, say GET / , then APM sets up a session (sets session cookies etc) and does a 302 redirect to /my.policy, where the interactive authentication occurs. After successful authentication there is another 302 redirect to the requested page or whatever is in the APM Policy flow. Now in this scenario, if the user initially sends a POST request with form data (in the payload), the initial 302 redirect does not preserve it.
Losing POST data is normal behaviour for 302 redirects, 302 also changes the http method to GET. A 307 redirect would preserve method and the POST data. I believe the 302 redirect is built in by design for the interactive authentication.
There is a way to avoid the 302 redirects using clientless-mode header in the request. But this is typically used with a non-browser client like a client application. There the request needs to have clientless-mode: 1 header. I believe the authentication needs to be done by other than interactive means in this case. I have only used 401 to invoke the client to send the credentials in Authorization header to APM in clientless mode. The credentials are stored in session variables for further use towards the server if needed, like in normal interactive authentication.
Vinne73_96575Andy, did you get any answer to your support call?
Same problem here: initial POST to an unauthenticated user, and all POST data is lost forever.
- Vinne73
Cirrus
Andy, did you get any answer to your support call?
Same problem here: initial POST to an unauthenticated user, and all POST data is lost forever.
- Andy_Turner
Sorry, no I didn't get anywhere with it, partly because I was able to solve the issue another way. We asked the Service Provider to send the requests using another method (instead of HTTP POST).
I don't seem to have even had a response to the call I put in other than the initial confirmation I'd submitted one, and it doesn't even appear in my list of calls on the support site...
Assuming you're having issues with a SAML Service Provider submitting POST data, perhaps you could ask them about doing it differently too?
- Andy_Turner
Just spotted this newer article that may solve this problem: https://devcentral.f5.com/s/articles/support-for-post-preservation-when-apm-multidomain-sso-is-configured-1097
I've not tested it myself.
