Forum Discussion

Youssef_Ghorbal's avatar
Mar 14, 2016
Solved

Portal Access, APM and Routing Domains

I have some "internal" web applications, some with Access Policies handled by the APM Module (SAML auth, Basic auth etc) VIPs of these web applications are spread across a couple Routing Domains (RD1 and RD2) I have a third Routing Domain (RD3) that hosts VIPs for public facing traffic.

 

I want to make the internal web applications accessible trough a Portal Access (APM) The portal works fine for non authenticated applications (ones without Access Policies) but It does not work for ones with access policies handled by APM. What happens is :

 

  1. user authenticate to the portal
  2. user click on the internal application link
  3. user is prompted to authenticate according to the Access Policy associated with that app.
  4. upon successful auth, user is redirected to the portal landing page (instead of the app)

After some digging, the problem seems to be that we have an APM sandwich situation and therefore APM session cookie collision. The portal is providing the client with an APM session cookie, and the app is trying to provide the client with another APM session cookie. The problem is well described in this DevCentral post

 

I also noted that when Portal VIP is within RD1 for example (not the RD3) It works fine for all applications within that Routing Domain. The APM session cookie got when first accessing the Portal is accepted when accessing the applications behind (when these applications are within the same RD as the portal.)

 

I think, my options are :

 

  1. Handle the situation with some iRule magic tricks to translate the inner APM cookie back and forth (as described in the post earlier)
  2. Have all the apps (and the portal) within the same RD, and using a Reverse Proxy VIP (in RD3) pointing to the portal internal VIP.
  3. Find a magic trick to tell the BigIP to ignore the RD segregation when evaluating APM sessions. I can't seem to find anything in the GUI or the documentation regarding this.

General thought : It seems surprising that F5 did not thought about the fact that sooner or later APM modules will get chained/stacked (they have a successful product after all :p ) In my situation I have control over the portal and the apps, in other use cases, you can be in a situation when you have to provide the Portal and another person/organisation is handling the app (with their own BigIP box)

 

Any thoughts ? Any suggestions ?

 

  • This particular issue has disappeared when we upgraded to 12.1.1 code. I can't find anything bout it in the change logs though.

     

1 Reply

  • This particular issue has disappeared when we upgraded to 12.1.1 code. I can't find anything bout it in the change logs though.