controlling APM access policy from iRule

There's actually a few places you can set an access policy variable.

• The HTTP_REQUEST event - while this is certainly one place you can set an access session variable, you have to be careful when you set it. As you found out, you had to wait for the client to request /my.policy because there's no access session token prior to this request.

• The ACCESS_SESSION_STARTED event - this event fires, as the name implies, at the beginning of the session, and unlike the HTTP_REQUEST event, is guaranteed to be inside the access session.

• A standard variable assignment agent in the visual policy.

• The ACCESS_POLICY_AGENT_EVENT - assuming you have an iRule event agent in the visual policy BEFORE the agent that needs to do the evaluation, this is a great way to drop into an iRule during policy evaluation to do something crafty, and then proceed. If you have multiple iRule event agents in the visual policy, make sure they all have different ID values, and then you can evaluate the ACCESS::policy agent_id value in this event to fire different code at different points in the visual policy from within the same event. Example:

  when ACCESS_POLICY_AGENT_EVENT {    
      switch [ACCESS::policy agent_id] {        
          "TAG_ID_1" {            
               do something here                
              ACCESS::session data set session.custom.foo "bar"                
          }            
          "TAG_ID_2" {            
               do something here                 
              if { [ACCESS::session data get session.custom.foo] equals "bar" } {
                  ACCESS::session data set session.custom.hello "world"           
              }                
          }            
      }
  }
  

thanks (as always) Kevin, your pointers got me where i wanted to be, working perfectly now.

Hi friends , I am new to f5 Apms -irules in particular , I would like some hands on my scenario . We have got multiple clients whose session MAX & Inactivity timeouts needs to be different from one another .

The resource assignment for the clients are based on the AD group. I've manged to put together a irule and decided to call this irule in the APM Policy just after ad query .

I wonder whether this irule script is correct ? and on the apm policy editor , when i select irule-event there is an field where i need to type in Custom-iRule-Event-Agent- ID which is i believe is the irule name !!!

when ACCESS_POLICY_AGENT_EVENT { set AdGroup [ACCESS::session data get "session.ad.$name.attr.group.$attr_name"] switch -exact "$AdGroup" { Standard_SSL_Users { ACCESS::session data set session.inactivity_timeout 150 ACCESS::session data set session.max_session_timeout 200 }{ log local0.notice "Inactivity and Max timeout set" } } }

Hi friends , I am new to f5 Apms -irules in particular , I would like some hands on my scenario . We have got multiple clients whose session MAX & Inactivity timeouts needs to be different from one another .

The resource assignment for the clients are based on the AD group. I've manged to put together a irule and decided to call this irule in the APM Policy just after ad query .

I wonder whether this irule script is correct ? and on the apm policy editor , when i select irule-event there is an field where i need to type in Custom-iRule-Event-Agent- ID which is i believe is the irule name !!!

when ACCESS_POLICY_AGENT_EVENT { set AdGroup [ACCESS::session data get "session.ad.$name.attr.group.$attr_name"] switch -exact "$AdGroup" { Standard_SSL_Users { ACCESS::session data set session.inactivity_timeout 150 ACCESS::session data set session.max_session_timeout 200 }{ log local0.notice "Inactivity and Max timeout set" } } }

Try this iRule instead, you must map ActivityTimeout as the Agent ID within the VPE. You also must attach the iRule to the virtual in the normal fashion.

when ACCESS_POLICY_AGENT_EVENT { 
    switch [ACCESS::policy agent_id] {
        "ActivityTimeout" {
            switch -glob [ACCESS::session data get "session.ad.last.attr.memberOf"] { 
                "*Standard_SSL_Users*" { 
                    ACCESS::session data set session.inactivity_timeout 150
                    ACCESS::session data set session.max_session_timeout 200
                    log -noname accesscontrol.local1.notice "01490000:7: [ACCESS::session data get "session.user.sessionid"]: [IP::client_addr]:[TCP::client_port]: --- Inactivity and Max timeout set ---"
                }
            }
        }
    }
}

Thanks for the reply ,is it same rule applies even when multiple ad-group/clients needs different timeout settings ?. i attached a copy of the policy ...

Thanks for the reply ,is it same rule applies even when multiple ad-group/clients needs different timeout settings ?. i attached a copy of the policy ...

Just add more switch cases for your additional groups.