Need Help: APM - Assigning Static ACLs by username

The ACCESS:acl command is only valid under the ACCESS_ACL_ALLOWED and ACCESS_ACL_DENIED events. These are the last events that fire in an access policy evaluation, and generally the only ACCESS events that fire after policy evaluation (per request after authentication).

Thank you for pointing that out, Kevin. I've adjusted my script accordingly, but am having a difficult time getting the iRule to launch in my access policy. Either the script isn't being activated, or it is being evaluated as having no effect on the session. So I have a question regarding access policies.

 

When I add an iRule action to the access policy in the VPE, it has a single field called ID. What is that asking for? I thought it required the name of the iRule I created under Local Traffic | iRules, but that didn't seem to be doing anything. Then I though maybe it was asking for the actual TCL code, but still nothing. I have read all the documentation I can find and nothing seems to answer this. Could you please shed some light on the iRule Event action? Thanks!

 

The ID is a flag passed to the iRule to indicate what you want... YOur iRUle has the event ACCESS_POLICY_AGENT_EVENT in it, and you access that value from the VPE object by \[ACCESS::policy agent_id\]

e.g. From devcentral wiki (https://devcentral.f5.com/wiki/iRules.ACCESS_POLICY_AGENT_EVENT.ashx)

when ACCESS_POLICY_AGENT_EVENT {
            if { [ACCESS::policy agent_id] eq "lastLogon" } {
                         our limit in seconds
                        set 2weeks 1209600
                         diff in 100 nanosecond increments between MS time attribute (year 1601) and start of epoch
                        set offset 11644473600000
                        set adtime "[ACCESS::session data get session.ad.last.attr.lastLogon]"
                         convert adtime to milliseconds
                        set millisecs [expr {$adtime / 10000}]
                         subtract offset
                        set lastlogintime [expr {$millisecs - $offset}]
                         convert to seconds because milliseconds for 'now' were negative (maybe vmware issue)
                        set secs [expr {$lastlogintime / 1000}]
                        set now [clock seconds]
                         finally calculate the difference
                        set diff [expr {$now - $secs}]
                        log local0. "lastLogon: $diff seconds from current time"
                        if { $diff > $2weeks } { 
                                    ACCESS::session data set session.custom.lastLogonWithin2Weeks 0
                        } else {
                                    ACCESS::session data set session.custom.lastLogonWithin2Weeks 1
                        }
            }
}

H

To elaborate on Hamish's excellent comments, the iRule processor is continually listening for events throughout a connection. APM's iRules event agent is the channel it uses to connect to the iRule processor, via the ACCESS_POLICY_AGENT_EVENT event, and the agent's ID is the point of entry. So you could easily have different APM iRules event agents firing at different points in the policy evaluation. Here's another example:

when ACCESS_POLICY_AGENT_EVENT {
   switch [ACCESS::policy agent_id] {
      "BEFORELDAP" { ...do something... }
      "AFTERLDAP" { ...do something... }
      "BEFORESSO" { ...do something... }
   }
}

Also, at different points in policy evaluation you may have access to session values that didn't exist until a specific agent fired (LDAP query, On-Demand Cert Auth, etc.), or you may need to insert an event before an agent to condition the variables for that agent. Lot's of possibilities.

OK thanks guys. This is starting to make sense to me. If ACCESS::acl eval is only usable from the ACCESS_ACL_ACCEPT or ACCESS_ACL_DENIED events, how do I get my access policy to trigger it if the VPE object only generates the ACCESS_POLICY_AGENT_ EVENT? My revised iRule code is as follows:

 

 

when ACCESS_ACL_ALLOWED {

 

 

variable varUser

 

 

set varUser [ACCESS::session data get "session.logon.last.username"]

 

 

ACCESS::acl eval $varUser

 

 

}

 

 

Secondly, does $varUser need to contain the partition of where the ACL is located, or just the name? Thanks!

1. All of the other ACCESS events are triggered automatically when the access policy evaluates. Only the ACCESS_POLICY_AGENT_EVENT event requires a manual trigger. Further, ACCESS_ACL_ALLOWED fires on every request after policy evaluation. You can kind of think of it like an HTTP_REQUEST event with guaranteed access to APM session values.

 

 

2. While you may not in some circumstances, it's best practice to include the partition information if not /Common.

 

Thanks again for that explanation, Kevin. You have helped me understand a lot more than when I started this thread. I think I found a different way of accomplishing what I want. I inserted a Variable Assign object in the policy and set it to ACLs with a value of expr {"/Common/[mcget {session.logon.last.username}]"} and it works! Now I can leave my policy alone and just create vendor acounts in AD along with static ALCs that match the vendor's username in the Edge Gateway. Provisioning vendor remote access should be a breeze now.