Forum Discussion
The normal way that LTM+APM / Web Access Management works is:
- User access https://apm.example.com/ - this is a GET for URI="/", from a web browser with no payload. This "/" URI is stored in a session variable in APM called "session.server.landinguri".
- APM gets request and respond with 302 to /my.policy with temporary session cookie
- User's browser GETs /my.policy
- APM responds with a logon page, message box, or whatever is in Access Policy
- 3+4 continue until Access Policy is complete
- APM 302s user to contents of variable "session.server.landinguri", stored from step 1. They also get the final session cookie.
- User GETs same thing as step 1, but now they have a session cookie and session is in "Allowed" state, so request is forwarded to pool attached to the virtual.
So that is normal operation. What about it is not good for your use case?
So basically you want APM to store all of the POST data and then present it back to the client in javascript form so that it can be re-POSTed by the browser at the end of the Access Policy?
We also have Clientless-Mode (look it up on Devcentral, it's sort of a "pass-through" function), but that can't work with RSA authentication because for RSA has to support interactive things like Next-Tokencode mode and New-PIN mode, which means the client browser has to be able to render things.
It seems complicated but possible. You'll have to grab the HTTP request data and store it somehow, and that will be the most complicated part.