Forum Discussion

NiHo_202842's avatar
NiHo_202842
Icon for Cirrostratus rankCirrostratus
Jun 29, 2015

How to run iRule after access policy

Hello,

I currently have a virtual server that provides access to specific nodes. This is protected with an access policy (AD auth + local check of username in data group by firing this iRule).

I have another iRule that is used to cherry-pick the node based on the URI.

Now without any access control, this works fine. But when my ac policy enabled, he first executes my node balancing irule and then my access policy. What is kind of strange.

Any suggestions?

My access policy; https://i.imgur.com/MZJH6y4.png

My irule user check;

when RULE_INIT {
   Enable for debugging
  set static::debug 1
   Name of the data group list for the entries, insert partition if necessary. e.g.; list or /UNIX/list
  set static::datalist "/UNIX/direct-access-list"
}
when ACCESS_POLICY_AGENT_EVENT {
    if { [ACCESS::policy agent_id] eq "checkdirectaccess" } {
        if {($static::debug eq 1)}{ log local0. "User [ACCESS::session data get "session.logon.last.username"]" }
        set found [class match -value [ACCESS::session data get "session.logon.last.username"] equals $static::datalist]
        if { !($found eq "")} {
            if {($static::debug eq 1)}{ log local0. "Access granted." }
            return
        } else {
            HTTP::respond 401 content "You are not authorized for access. Contact admin@company.com"
        }
    } else {
        if {($static::debug eq 1)}{ log local0. "Policy Agent ID not found: [ACCESS::policy agent_id]" }
    }
}
APM
application delivery
design
devops
iRules
security
TMOS

2 Replies

Sort By
  • Michael_Jenkins's avatar
    Michael_Jenkins
    Icon for Cirrostratus rankCirrostratus
    Jun 29, 2015

    I assume you're using the 

    HTTP_REQUEST
    event in your cherry-picking iRule?

    In that case, you may want to check out this article that shows the event flow with regard to APM connections.

    The 

    HTTP_REQUEST
    event is one of the first things to get executed (before any of the APM stuff happens). Because of this, you could do a couple things:

    1. Check for an 
      MRHSession
      cookie and then check the 
      [ACCESS::policy result]
      for 
      allow
      and if that's the case, perform your check on the uri.
    2. Handle the initial request from the 
      ACCESS_POLICY_COMPLETED
      event instead (or in addition to the HTTP_REQUEST event). Probably wouldn't recommend this one since it's more complex...

    Hope this helps.

  • Stefan_Klotz's avatar
    Stefan_Klotz
    Icon for Cumulonimbus rankCumulonimbus
    Jun 29, 2015

    Hi NiHo,

     

    I'm currently working on a similar setup and I'm using the table command to get it working (I'm using 10.2.4 in my setup).

     

    My APM policy is doing a LDAP query and I'm using two attributes, one for redirecting the user to the correct start-URI and the other to dynamically choose the correct pool and poolmember. I've learned that the "ACCESS_POLICY_AGENT_EVENT" is triggered only once, but for pool assignment or redirects the "HTTP_REQUEST"-event is required, which fires much more (and also before the "ACCESS_POLICY_AGENT_EVENT").

     

    Therefor at the end of the "ACCESS_POLICY_AGENT_EVENT" I created some session variable with the table command (specifying the same timeout as the APM policy has, 900 by default). In the "HTTP_REQUEST"-event I verify with the table lookup command if the session variable is already set (which also extends the timeout as long as the user is active). And for the logout, which will be triggered with a specific URI in my setup, I delete all the session variables again.

     

    I hope this will point you in the right direction.

     

    Ciao Stefan :)