Recently I was helping a customer address a multi-factor authentication bug where the 3rd party MFA solution would post the username and temporary token back to APM via the wrong URL. While we worked with the partner to address this bug the customer needed a work around in the meantime… perfect time for an iRule!
For those not intimately familiar with APM when a client accesses the / URL APM create a session and responds with a 302 status code that:
- sets the MRHSession cookie variable with the session id
- redirects the browser to /my.policy to start the authentication process
If you issue another HTTP request to anything other than /my.policy APM will kill the previous session and create a new session; even if you include the MRHSession cookie in the HTTP header.
In our case we needed the MFA to post the username and token back to the /my.policy URL instead of the / URL. My first thought was “this is easy enough”:
when HTTP_REQUEST {
if {[ACCESS::policy result] eq "not_started" && [string tolower [HTTP::url]] eq "/"
&& [string tolower [HTTP::header "Referer"]] contains "mfa.company.com"} {
HTTP::redirect "/my.policy"
}
}
However, we quickly figured out that while the browser honors the 302 and directs the user to /my.policy the browser does not POST the username and temporary token to the /my.policy URL after the redirect… this quickly put a damper on the iRule magic. A quick Google search mentioned using a 307 status code to redirect an HTTP POST method. I had never seen/used a 307 HTTP status code so this was new to me. So we updated the iRule accordingly:
when HTTP_REQUEST {
if {[ACCESS::policy result] eq "not_started" && [string tolower [HTTP::url]] eq "/"
&& [string tolower [HTTP::header "Referer"]] contains "mfa.company.com"} {
HTTP::response 307 Location "/my.policy"
}
}
Sure enough that did the trick and forced the browser to post the username and temporary token to the /my.policy URL which allowed us to avoid creating a new APM session every time the user finished their MFA process.
Cody Green 