Manual : Per-Request Policy Concepts

Applies To:

  • BIG-IP APM

    15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0

Per-Request Policy Concepts

Zero trust follows the principle never trust, always verify and thus enforces authentication and verification for every user or device attempting to access resources whether from within or outside of the network.

The easiest way to create policies to support zero trust security is to use the Zero Trust-Identity Aware Proxy template in Access Guided Configuration. The template takes you through the steps needed to create an Identity Aware Proxy. Access Policy Manager (APM) acts as the Identity Aware Proxy helping to simplify client access to both multi-cloud and on-premise web applications, and securely manage access from client devices.

On APM, you can develop per-request policies with subroutines that perform different levels of authentication, federated identity management, SSO (single sign on), and MFA (multi-factor authentication) depending on the requirements. Subroutines perform continuous checking based on a specified duration or gating criteria. Policies can be as complex or as simple as you need them to be to provide seamless yet secure access to resources. Refer to Implementing Zero Trust with Per-Request Policies for many examples of per-request policies that implement different aspects of zero trust.

For additional security, device posture checking provides instantaneous device posture information. The system can continuously check clients to be sure, for example, that their antivirus, firewall, and patches meet company requirements, ensuring that the device maintains trust at all times.

On the client side, F5 Access Guard allows real-time posture information to be inspected with per-request policy subroutines. F5 Access Guard generates posture information asynchronously, and transparently transmits it to chosen APM server endpoints using special HTTP headers. Refer to BIG-IP Access Policy Manager: Configuring F5 Access Guard for details on client requirements.

APM executes per-session policies when a client attempts to connect to the enterprise. After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. Because of this behavior, a per-request policy is particularly useful in the context of a Secure Web Gateway or Zero Trust scenario, where the client requires re-verification on every request, or changes based on gating criteria.

A per-request policy can include a subroutine, which starts a subsession. Multiple subsessions can exist at one time.

You can use nearly all of the same agents in per-request policies that you can use in per-session policies. However, most of the agents (including authentication agents) have to be used in a subroutine in per-request policies.

A per-request policy subroutine is a collection of actions. What distinguishes a subroutine from other collections of actions (such as macros), is that a subroutine starts a subsession that, for its duration, controls user access to specified resources. If a subroutine has an established subsession, subroutine execution is skipped. A subroutine is therefore useful for cases that require user interaction (such as a confirmation dialog or a step-up authentication), since it allows skipping that interaction in a subsequent access.

Note: You cannot use subroutines in macros within per-request policies.

Subroutine properties specify subsession timeout values, maximum macro loop count, and gating criteria. You can reauthenticate, check for changes on the client, or take other actions based on timeouts or gating criteria.

A subsession starts when a subroutine runs and continues until reaching the maximum lifetime specified in the subroutine properties, or until the session terminates. A subsession populates subsession variables that are available for the duration of the subsession. Subsession variables and events that occur during a subsession are logged.

Multiple subsessions can exist at the same time. The maximum number of subsessions allowed varies across platforms. The total number of subsessions is limited by the session limits in APM (128 * max sessions). Creating a subsession does not count against the license limit.

You can use gating criteria in the subroutine properties to allow the same subroutine to control multiple subsessions. A distinct subsession is created for each distinct gating criteria value. In the Gating Criteria field in the subroutine properties, you can select a perflow variable (such asperflow.client.ip.address), or you can specify a Tcl expression (such as expr {[mcget {session.logon.last.username}]}).

The gating criteria value is the value that results from evaluating the specified gating criteria expression, which is the value stored in the selected perflow variable, or the value computed from a iRule/Tcl expression. If you leave the Gating Criteria field blank, the subroutine runs once and applies the same ending to all requests for resources for the duration of the subsession.

APM uses the value in this field to determine whether to run the subroutine. If a subsession already exists for the particular resource (such as a URL or an application) or the group of resources (such as those represented by a URL category or an application family), APM does not run the subroutine again for the current request, but uses the same subsession, applying the result that was obtained when the subroutine ran.

If APM does not find a matching subsession, APM validates the gating criteria before running the subroutine. If the field contains a perflow variable, APM looks up its value. If the perflow variable does not contain a value, APM returns an error. (The per-request policy must be configured to provide a value for the perflow variable before you’re trying to use it.) If the perflow variable contains a valid value or if the gating criteria is blank, APM runs the subroutine.

Here are some examples of gating criteria that you can use in a subroutine:

  • perflow.client.ip.address– You can use this variable as gating criteria for requests to double check whether the user’s IP address has changed since the subsession started. So if, for example, the user moves from a wired to a wireless network connection, you can ask again for user credentials.
  • expr { [ mcget {session.adStepUpAuth.gatingCounterPath} ] }– To use this variable as gating criteria, another part of the policy needs to populate the session variable session.adStepUpAuth.gatingCounterPath