I'm having this issue where APM-protected content fails to start APM session if called from an iFrame.
The access session starts at client request time as expected, and I can see that APM responds with the redirect to /my.policy setting unique access session cookies (MRHSession, LastMRH_Session) . I have noticed that when iframe tries to load GET /my.policy request, it does not retain those cookies, which I suspect being the reason request fails. My access session times out with 0 received packets, from packet capture I see APM redirects client to /my.logout.php3?errorcode=19 page and on iFrame content I see APM page with "Access Denied" message.
Has anyone had this issue before? Any input is appreciated.
So we did some more testing, and this is not going to work.
We've worked with support and experimented with iRules to insert additional headers and cookies into the response, but the behaviour of CORS is that these are always going to be removed. And because APM relies heavily on cookies to function, it does mean that accessing APM-protected content from an iFrame will fail to work.
i found the way to prevent the dialog breaks out of the frame :
go to the Access Policy -> Customization -> Advanced
go to Access Profiles / / Access Policy / Logon Pages / Logon Page / logon.inc
Search for if(self != top) { top.location = self.location; } and comment it out so it looks like this: //if(self != top) { top.location = self.location; }
@momahdy I'm running BIG-IP version 16, logon.inc seems related to previous software versions and I have not found similar code in other ".inc" pages within advanced APM policy configuration menu.
@CA_Valli I tried a quick lab with v16.1.2 and can find it in line 140 this is using standard type not the modern type. in case issue still persist it would be very helpful to raise a case to support so that they can better inspect your environment specifically.
So we did some more testing, and this is not going to work.
We've worked with support and experimented with iRules to insert additional headers and cookies into the response, but the behaviour of CORS is that these are always going to be removed. And because APM relies heavily on cookies to function, it does mean that accessing APM-protected content from an iFrame will fail to work.
Hello Aubrey, thanks for your input. We haven't tried Oneconnect, but since APM is in place and we're getting errors at authentication time, the BIG-IP never really forwards these packets to back-end anyways.
iRule kinda looks like this. I suggest you to raise a support case if you need specific tuning.
when HTTP_REQUEST {
if { $host eq "apmprotected.mybusiness.com" && [HTTP::header exists "Referer"]}{
set referer_host [string tolower [URI::host [HTTP::header "Referer"]]]
if { $referer_host ne "partnerportal.company.com" && $referer_host ne "apmprotected.mybusiness.com"}{
# iframes in unauthorized portals get redirected to main auth
# notice I had to include my own portal as "authorized" to correctly load scripts,css,etc.
HTTP::respond 302 Location "https://apmprotected.mybusiness.com/"
} else {
# i have a big list of IFs here to match specific conditions
ACCESS::disable
}
}
}
