Forum Discussion
5 Replies
- Lucas_Thompson_Historic F5 Account
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?
- Stanislas_Piro2Cumulonimbus
I agree this is the normal operation, but only if the request method is GET.
If the request method is POST, the step 7 will be replaced by GET and may cause an issue.
- Lucas_Thompson_Historic F5 Account
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.
- Yaoxie_117356Nimbostratus
Hi Lucas, thanks for your reply.
My initial question has been fixed now
My second question is sometimes there is HTTP request generated by some script which ignore the MRH session cookie (assuming browser had already passed APM policy) and result in 302, in this scenario, except for disable ACCESS:SESSION, what's the other way around?
- Lucas_Thompson_Historic F5 Account
You have to be able to somehow either associate the new request with the old session (you could insert the session cookie in an irule after it had been stored in a subtable from some other irule operation)
Or just start up a new session in clientless-mode if you have HTTP authorization data.