Initiating Access Policy from iRules

I believe it's specifically talking about the new ACCESS::policy evaluate command:

https://devcentral.f5.com/wiki/iRules.ACCESS__policy.ashx

What's your use case specifically?

I'd like to put together some examples and am looking for direction in this area.

Hi

is there any following up on this? what i am thinking is if i can apply different APM access policy based on the different domain name that arrives on the same virtual server.

technically i can achieve the same result based on VPE but the reason why i want to have different policy is so that i can configure different ACL and authentication for different domain name and leaves it cleanly.

if use do all the nesting within a single policy and uses the VPE to branch out based on domain name, as the number of domain name increases, it will make the single policy "fatter".

why i dont do one vs per domain name? I runs out of public IP to use.

Currently there's no way to dynamically switch between access policies in a single VIP. The ACCESS::policy evaluate command will indeed allow you to assign an access policy to a given request, but it does so in a limited fashion and is not really intended for HTTP traffic. Probably the best way to switch between policies based on the URL is simply to layer an LTM VIP over individual APM VIPs. Create your APM VIPs on port 80 with internal (non-routable) addressed. Create a single external LTM VIP with your publicly-accessible IP, client SSL profile (if required), and an iRule like this:

when HTTP_REQUEST {
    switch [string tolower [HTTP::host]] {
        "www1.domain.com" { virtual apm1_vs }
        "www2.domain.com" { virtual apm2_vs }
    }
} 

where the virtual command forwards the request internally to the named VIP.

Hi Kevin

thanks for the advice. That was the first irule that I did but it didnt works. For some reasons, it didnt get re-directed to another VS. I am thinking if it is because of the limited license of the Edge Gateway.

Hi everyone,

we have the same problem here. Concept is basically to have another type of SAML auth when going to /admin URI. Using the iRule above does not do the trick for us. It looks like this:

when HTTP_REQUEST {
    if { [string tolower [HTTP::uri]] starts_with "/admin" } {
      virtual apm_vs_ldap
    } else {
      virtual apm_vs_eid
    }
}

When using log we can see that the iRule if-statement get hit when using URI /admin. BUT we still use the Access Policy for VIP apm_vs_eid? This is strange, we have no idea why this is happening. Anyone have an update on this problem? Or is there any other way to use different Access Policys for the same VIP depending on the URI?

Cheers // Mattias

During Access Policy execution, you can have a chooser based on incoming URI, so you can run different logic. It doesn't necessarily have to be a separate access policy. Further, during access policy execution, you can choose a pool, so you could choose one pool based incoming URI A and another for incoming URI B (we call it a "landing uri"). Are you sure it needs to be a different access policy? User sessions are global on the box anyway, so there's not really any difference between a user completing one or another.

Well, that sounds good. But we tried a similar approach and when using the intellegence of Landing URI in Access Policy you can actually go between /admin and the default URL, so the Access Policy do not evaluate the rules once it have hit success. And i cannot see how we can use different pools when the web application use the same servers, its only /admin URI on the webserver. We have discussed different solutions, maybe use "Per request" AP to evaluate the rules everytime, but we dont know how that will affect performance in APM. Its not a big deal, we can always have the lgoin in the application and not in APM. I was just courious if it was possible.

The iRule above will not work because when you hit the AccessPolicy of one of the VIPs it will redirect to the URI /my.policy and then break the matching URI and fallback to the else-statement.