HTTP Event Order -- Access Policy Manager

Early last year I blogged an update to the iRules HTTP event order that F5er John Alam put together. John is back with another update to the drawing, this time, however, including the access policy manager flow. This article will cover the APM events as well as a couple new standard events added back in 11.0.

APM Event Flow

There are a plethora of events and commands specific to the access policy manager in iRules, which you can find here on Clouddocs. I’ll focus on the events in this article. Of the eight events, there are only a few events triggered per request.

• ACCESS_ACL_ALLOWED – triggered right after HTTP_REQUEST (and before CACHE_REQUEST, not included in this drawing) for a request that has been allowed by ACLs. ACCESS checks the request for a valid session, valid policy result, and then evaluates ACLs. If ACL allows a request, it raises ACCESS_ACL_ALLOWED before releasing the request to the upper layers.
• ACCESS_ACL_DENIED – same process as ACCESS_ACL_ALLOWED, but triggered before the request is denied (by redirecting the request to access denied page)
• REWRITE_REQUEST_DONE – triggered right after ACCESS_ACL_ALLOWED when a portal access resource is accessed.

The other events are only triggered at some specific processing for a user’s session and access policy. For the ACCESS_POLICY_* events, even though the user’s flow is utilized, the events are triggered in the context of the APM internal request as dictated by the policy.

• ACCESS_SESSION_STARTED – triggered right after HTTP_REQUEST (before CACHE_REQUEST) when a request is received with no SID or an invalid SID.
• ACCESS_SESSION_CLOSED – triggered from an internal timer when session is being deleted. This is not triggered in a traffic flow context.
• ACCESS_POLICY_COMPLETED – triggered when access policy completes.
• ACCESS_POLICY_AGENT_EVENT – triggered when during access policy execution, and iRule event agent is executed.
• REWRITE_RESPONSE_DONE – only triggered if REWRITE::post_process is enabled in the REWRITE_REQUEST_DONE event.

A majority of the APM flows occur on the request side, as shown below:

A little further down the processing path on the response flows is the final APM event:

Hidden Events

For APM internal URIs, like /my.policy and /my.logout, the HTTP_REQUEST/HTTP_RESPONSE events don’t fire as you would expect beginning in v11.x. The traditional method to work around this (and other module complexities) is to use the vip targeting vip configuration, where you can have a backend or frontend (or both!) virtual in which to do your iRule processing and another virtual to host the module (APM/ASM/etc). However, with APM, if you require access in your iRules to these internal URIs, you can use the ACCESS::restrict_irule_events command in the CLIENT_ACCEPTED event to expose them. An example:

when CLIENT_ACCEPTED {
  ACCESS::restrict_irule_events disable
}
when HTTP_REQUEST {
  if { [HTTP::uri] ends_with "/my.logout.php3?errorcode=19" } {
    HTTP::redirect "/"
  }
}

New Events

The plugin architecture for TMOS that APM uses results in a lost view/inspection point at the iRules level of what exactly hits the wire when the request is released to the server or the client. However, two new events were added in v11.0 to provide these last chance inspection points, aptly named HTTP_REQUEST_RELEASE and HTTP_RESPONSE_RELEASE. On the serverside, you can now inspect what APM (or any other module) has done to the request before it hits the wire on the way to the server, and likewise, on the clientside, what APM has done to the response before it hits the wire on the way to the client.

Putting It All Together

Now that the pieces have been dissected, the diagram in its entirety should come together a little easier.

Drawing: BIGIP_Events_Visio.pdf