Forum Discussion

JD1's avatar
JD1
Icon for Altostratus rankAltostratus
Jul 10, 2019
Solved

APM - Multiple sessions per single VS and APM profile/policy.

Hi All,

 

I've a scenario where multiple URLs land on a policy and the result is determind by the URL originally reached.

As expected though, once the policy is completed for one browser session against a particular URL, the other URLs do not start a policy and expect to be routed through to pool resources for the original.

 

Is there a simple way of triggering a new session per URL under a single VS and policy?

 

Things I've considered otherwise.

 

1)

Landing VS, that redirects to multiple VS's using higher ports.

Thus effectively having a multiple VS and multiple policy scenario.

 

2)

Landing VS, that redirects to multiple VS's using higher ports.

Thus effectively having a multiple VS and single policy scenario.

 

3)

Some sort of iRule with tables to force starting of a session based on URL.

Seems more complicated on this one.

 

 

I'd ideally like logic to be in the policy to say, "Hey you came for URL-A the first time and got a session, but this time you want URL-B. Let's prompt again"

 

Many thanks,

 

JD

 

 

  • It is not dedicated only to SWG, you can use with APM also to improve security of a webtop for example. When you attach a per-request policy to your VS, all your client requests are evaluated by this policy.

     

    With a URL_branching box at the begining of the policy, you can decide what action to perform (like a new authentication) according to the URL requested by the client. The session variable to use is "perflow.category_lookup.result.url". Hope it's clear.

7 Replies

  • It is not dedicated only to SWG, you can use with APM also to improve security of a webtop for example. When you attach a per-request policy to your VS, all your client requests are evaluated by this policy.

     

    With a URL_branching box at the begining of the policy, you can decide what action to perform (like a new authentication) according to the URL requested by the client. The session variable to use is "perflow.category_lookup.result.url". Hope it's clear.

    • JD1's avatar
      JD1
      Icon for Altostratus rankAltostratus

      Thanks for the reply.

    • JD1's avatar
      JD1
      Icon for Altostratus rankAltostratus

      Just to update on this - This seems to be only applicable if you're using LTM_APM mode(?).

       

      So far as I can see, if I want to apply things to connectivity resources then it's a no go.

       

      In the end, my solution was multiple VS forwarded from a landing VS using irules and the 'virtual' command.

      Each sub-VS then had an individual APM policy associated.

  • Hi,

     

    In case you don't know, since v12 there is per-request policy functionality available that allow you to implement step-up authentication easily (using the same session).

     

    You can find more information here: https://support.f5.com/csp/article/K42521259

    • JD1's avatar
      JD1
      Icon for Altostratus rankAltostratus

      My understanding that per-request is for Secure Web Gateway use only, which is why it talks about categorization.

       

      Correct me if I'm wrong on this, but I'm looking purely at an APM reverse proxy stand point to allow resources, but treat each application as a separately governed session.

      • JD1's avatar
        JD1
        Icon for Altostratus rankAltostratus

        Also, just to tack on the end of my last message - If Per-Request were to work outside of SWG, I believe that's protecting sub-areas of the same application. In this case I'm presenting different applications per host header, which need to be evaluated individually for the entire application.

         

        Many thanks,

        JD

  • That works with LTM+APM mode and webtop mode also. I never tried with connectivity ressource like RDP or VPN, only with portal access. If the URL requested when clicking on the resource can be determined, then per-request policy can be invoked.

     

    As you described your solution, a per-request policy instead of an iRule should be possible normally. The advantage of that is to keep the same APM session between each VS.