F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP APM
  4. BIG-IP Access Policy Manager: Secure Web Gateway Implementations
  5. Per-Request Policy Configuration
Manual Chapter : Per-Request Policy Configuration

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 12.0.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Per-Request Policy Configuration

About access and per-request policies

Secure Web Gateway (SWG) uses two types of policies.

Access policy
The access policy runs when a client initiates a session. Depending on the actions you include in the access policy, it can authenticate the user and perform group or class queries to populate session variables with data for use throughout the session.
Per-request policy
After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. A per-request policy must provide the logic for determining how to process URL requests. Depending on the actions you include in the per-request policy, it can control whether or not to bypass SSL traffic and must determine whether to allow or reject a URL request.

An access policy and a per-request policy are both specified in a virtual server.

Overview: Configuring a per-request policy

A per-request policy must specify the logic that determines how to process URL requests whether they are requests for web access (in a forward proxy configuration) or requests for internal resources (in a web access management configuration). How to make that determination is largely up to you.

To put SSL forward proxy bypass (specified in client and server SSL profiles) into effect, the per-request policy must ultimately determine whether to intercept or bypass the SSL traffic. If you plan to process SSL traffic, configure the policy to complete that processing first.

To put URL categorization into effect, the per-request policy must be configured to look up the URL category and assign the URL filter that allows or blocks URL requests.

To base processing of URL requests on a user group or user class, per-request policy items that look up a user group or user class read values stored in session variables. To ensure that the values are available, the access policy that creates the session must be configured with actions that populate the session variables.

Task summary

After you create the per-request policy, use any of the remaining tasks to add items to it to build the per-request policy that you need.

Task list

About Response Analytics and the order of policy items

Note: The Response Analytics per-request policy item is for use only on a BIG-IP® system with an SWG subscription.

The Response Analytics per-request policy item makes an HTTP request and waits for the HTTP response before it completes. As a result to function properly, any policy items that rely on the information in the HTTP request or that attempt to modify the HTTP request must always precede the Response Analytics item. Specifically, the Category Lookup and HTTP Headers items must not follow a Response Analytics item.

Important: You must enforce this ordering to ensure that your per-request policy functions as you intend.

About SSL Bypass Set and SSL Intercept Set and the order of policy items

To ensure that SSL Bypass Set and SSL Intercept Set work correctly, do not place them in a per-request policy after any of these items:

  • Category Lookup, if configured to use HTTP URI for input
  • Response Analytics
  • URL Filter Assign
  • HTTP Headers
  • Application Lookup
  • Application Filter Assign

About the SSL Bypass Set and SSL Intercept Set process

For SSL bypass or SSL intercept actions, Secure Web Gateway (SWG) forwards the client hello directly to the server. The client and server then negotiate SSL parameters. This must occur before any per-request policy item inspects the SSL payload (HTTP data). Everything that the policy does before an SSL Bypass Set or SSL Intercept Set policy item must operate either on SSL data (certificate or client hello) or on session data (which is not part of SSL payload).

SSL bypass example

This example per-request policy bypasses all SSL traffic from users in the Directors group. For other users, the policy bypasses SSL traffic only if it falls into a category that raises privacy concerns, such as one in which financial data might be accessed. After a determination about whether to bypass or intercept SSL traffic is complete, the policy can then move from processing HTTPS data to processing the HTTP data in the SSL payload.

policy with protocol lookup, group lookup, category lookup, and ssl bypass set

SSL bypass decision based on group membership and URL category

1 For directors, do not intercept and inspect any SSL request. To bypass the traffic, use the SSL Bypass Set item.
2 To use Category Lookup to process HTTPS traffic, you must configure it to use SNI or Subject.CN input.
3 For users that are not in the Directors group, do not intercept and inspect SSL requests that contain private information. Bypass the traffic by inserting the SSL Bypass Set item.
4 After the policy completes HTTPS processing, you can start to process HTTP data. Continue with actions, such as URL Filter or Application Lookup, that inspect the SSL payload. The URL Filter item determines whether to allow or reject traffic.

(For this example to be valid, both the server and client SSL profiles on the virtual server must enable SSL forward proxy and SSL forward proxy bypass; the client SSL profile must set the default bypass action to Intercept.)

URL filter per user group example

Each URL Filter Assign item in this per-request policy example should specify a filter that is applicable to the user group.

Group lookup followed by branches for specific groups and a URL filter assignment for each.

URL filter based on group membership

Access control by date, time, and user group example

This per-request policy example applies specific URL filters for weekends and weeknights, and restricts access during work hours based on user group.

Policy that restricts access except for weekends, after hours, and sales group

Deny or allow access based on date and time and group membership

Response Analytics example

In this example per-request policy, a Category Lookup item obtains a list of categories and a response web page. If Category Lookup returns a value that specifies the response needs to be scanned to determine the appropriate category, Response Analytics runs.

Response Analytics scans the response for malicious embedded content and passes an analysis to the URL Filter Assign item. URL Filter Assign uses the analysis, if provided, and the specified filter to determine whether to allow the request.

Note: Response Analytics is for use only on a BIG-IP® system with an SWG subscription and is not applicable in a web access management configuration.
Policy with category lookup, response analytics, and URL filter assign

Process of Response Analytics contributing analysis results to URL filter assign

Category-specific access control example

In this per-request policy example, only recruiters are allowed to access URLs in the job search category. The policy also restricts access to entertainment sites during business hours.

Policy that restricts the Entertainment category to weekends and the Jobsearch category to recruiters.

Category-specific access restrictions

Application lookup and filter example

Application lookup and application filter assign in a per-request policy

Application access control by application family, application name, and application filter

1 A user-defined branch for the instant messaging application family.
2 A user-defined branch for a specific application.
3 The default fallback branch, on which an application filter is applied. Application Filter Assign needs the information provided by Application Lookup.
Note: The Application Lookup and Application Filter Assign policy items are not supported in a Secure Web Gateway remote access forward proxy configuration or in a web access management configuration.

Creating a per-request policy

You must create a per-request policy before you can configure it in the visual policy editor.
  1. On the Main tab, click Access Policy > Per-Request Policies .
    The Per-Request Policies screen opens.
  2. Click Create.
    The General Properties screen displays.
  3. In the Name field, type a name for the policy and click Finished.
    A per-request policy name must be unique among all per-request policy and access profile names.
    The policy name appears on the Per-Request Policies screen.

Processing SSL traffic in a per-request policy

To use SSL forward proxy bypass in a per-request policy, both the server and client SSL profile must enable SSL forward proxy and SSL forward proxy bypass; and, in the client SSL profile, the default bypass action must be set to Intercept.
Important: Configure a per-request policy so that it completes processing of HTTPS requests before it starts the processing of HTTP requests.
Note: These steps describe how to add items for controlling SSL web traffic to a per-request policy; the steps do not specify a complete per-request policy.
  1. On the Main tab, click Access Policy > Per-Request Policies .
    The Per-Request Policies screen opens.
  2. In the Access Policy column for the per-request policy that you want to update, click the Edit link.
    The visual policy editor opens in another tab.
  3. To process the HTTPS traffic first, configure a branch for it by adding a Protocol Lookup item at the start of the per-request policy.
    1. Click the (+) icon anywhere in the per-request policy to add a new item.
      A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
    2. In the Search field, type prot, select Protocol Lookup, and click Add Item.
      A properties popup screen opens.
    3. Click Save.
      The properties screen closes. The visual policy editor displays.
    The Protocol Lookup item provides two default branches: HTTPS for SSL traffic and fallback.
  4. Before you add an SSL Bypass Set, or an SSL Intercept Set, item to the per-request policy, you can insert any of the following policy items to process SSL traffic:
    • AD Group Lookup
    • LDAP Group Lookup
    • LocalDB Group Lookup
    • RADIUS Class Lookup
    • Dynamic Date Time
    • Logging
    • Category Lookup
      Important: Category Lookup is valid for processing SSL traffic only when configured for SNI or Subject.CN categorization input and only before any HTTP traffic is processed.
    If you insert other policy items that inspect the SSL payload (HTTP data) before an SSL Bypass Set item, the SSL bypass cannot work as expected.
  5. At any point on the HTTPS branch where you decide to bypass SSL traffic, add an SSL Bypass Set item.
The per-request policy includes items that you can use to complete the processing of SSL traffic. Add other items to the policy to control access according to your requirements.
A per-request policy goes into effect when you add it to a virtual server.

Configuring policies to branch by local database user group

If you plan to look up local database groups from the per-request policy, you must configure local database-related items in the access policy and the per-request policy to use the same session variable.
  1. On the Main tab, click Access Policy > Access Profiles .
    The Access Profiles List screen opens.
  2. In the Access Policy column, click the Edit link for the access profile you want to configure.
    The visual policy editor opens the access policy in a separate screen.
  3. On an access policy branch, click the (+) icon to add an item to the access policy.
    A popup screen displays actions on tabs, such as General Purpose and Authentication, and provides a search field.
  4. In the search field, type local, select Local Database, and click Add Item.
    A popup properties screen opens.
  5. Configure properties for the Local Database action:
    1. From the LocalDB Instance list, select a local user database.
    2. Click Add new entry
      A new line is added to the list of entries with the Action set to Read and other default settings.
    3. In the Destination column in the Session Variable field, type the name of the variable in which to store the user groups retrieved from the local database.
      In the per-request policy, the default value that the LocalDB Group Lookup item uses is session.localdb.groups. If you enter a differentvalue, note it. You will need it to update the advanced expression in the LocalDB Group Lookup item in the per-request policy.
    4. In the Source column from the DB Property list, select groups.
    5. Click Save.
      The properties screen closes. The visual policy editor displays.
    This is not a complete access policy, but you can return to it and complete it later. You can close the visual policy editor or leave it open.
    The access policy includes a Local Database action that can read groups into a session variable.
  6. On the Main tab, click Access Policy > Per-Request Policies .
    The Per-Request Policies screen opens.
  7. In the Access Policy column for the per-request policy that you want to update, click the Edit link.
    The visual policy editor opens in another tab.
  8. Click the (+) icon anywhere in the per-request policy to add a new item.
  9. In the search field, type local, select LocalDB Group Lookup, and click Add Item.
    A popup properties screen opens.
  10. Click the Branch Rules tab.
  11. Click the change link in the entry for the default expression.
    A popup screen opens.
  12. If the session variable you typed in the access policy Local Database action was session.localdb.groups, perform these substeps.
    1. In the User is a member of field, remove MY_GROUP and type the name of a group.
    2. Click Finished.
      The popup screen closes.
    3. Click Save.
      The properties screen closes and the visual policy editor displays.
  13. If you typed a session variable other than session.localdb.groups in the access policy Local Database action, perform these substeps.
    1. Click the Advanced tab.
      In the field, this expression displays. expression is expr { [mcget {session.localdb.groups}] contains "MY_GROUP" }
    1. In the expression, replace session.localdb.groups with the name of the session variable you typed into the Local Database action.
    2. In the expression, replace MY_GROUP with the name of a group that should match a local database group.
    3. Click Finished.
      The popup screen closes.
    4. Click Save.
      The properties screen closes and the visual policy editor displays.
    This is not a complete per-request access policy, but you can return to it and complete it later.
The access and per-request policies are configured to use the same session variable. The access policy is configured to support the use of LocalDB Group Lookup in the per-request policy.
Complete the configuration of the access and per-request policies.

Specifying URL categorization in a per-request policy

Look up the category for a URL request and assign a URL filter that blocks or allows access to control access to the web, based on the category of the URL request.
Important: This task includes some references to category lookup options and policy items that are supported only on a BIG-IP® system with an SWG subscription. They are: standard categories, SafeSearch support, and content scanning (Response Analytics).
Note: This task provides the steps for adding items to control web traffic based on the URL category. It does not specify a complete per-request policy.
  1. On the Main tab, click Access Policy > Per-Request Policies .
    The Per-Request Policies screen opens.
  2. In the Access Policy column for the per-request policy that you want to update, click the Edit link.
    The visual policy editor opens in another tab.
  3. Add a Category Lookup item.
    Important: A Category Lookup item triggers event logging for SWG, provides a response web page for the Response Analytics item (on systems that support it), and provides categories for the URL Filter Assign item.
    1. Select an entry from the Categorization Input list based on the type of traffic to be processed. For HTTP traffic, select Use HTTP URI (cannot be used for SSL Bypass decisions). For SSL-encrypted traffic, select either Use SNI in Client Hello (if SNI is not available, use Subject.CN) or Use Subject.CN in Server Cert.
      On a BIG-IP® system with an SWG subscription, if you select Use HTTP URI (cannot be used for SSL Bypass decisions), the SafeSearch Mode list displays and Enabled is selected.
    2. From the Category Lookup Type list, select the category types in which to search for the requested URL. On a system with user-defined categories only, the Process custom categories only item is the only choice. Otherwise, select one from Custom categories first, then standard categories if not found, Always process full list of both custom and standard categories, or Process standard categories only.
      Depending on the selection, the item looks through custom categories or standard categories or both, and compiles a list of one or more categories from them. The list is available for subsequent processing by the URL Filter Assign item.
    3. Click Save.
      The properties screen closes. The visual policy editor displays.
  4. Add a URL Filter Assign item anywhere on a branch after a Category Lookup item.
    In this item, you must specify a URL filter to apply to the URL categories that the Category Lookup item returned. If any URL category specifies the Block filtering action, URL Filter Assign blocks the request.
  5. To enable Safe Search for SSL-encrypted traffic on a BIG-IP® system with an SWG subscription, add an additional Category Lookup item with these settings:
    1. Specify Use HTTP URI (cannot be used for SSL Bypass decisions) as the Category Lookup Type
    2. Retain the default setting (Enabled) for SafeSearch Mode.
  6. To trigger inspection of the response web page contents on a BIG-IP® system with an SWG subscription, insert a Response Analytics item on a branch after a Category Lookup item and before a URL Filter Assign item.
    The Category Lookup item supplies a response web page. The URL Filter Assign item blocks the URL request if the Response Analytics item identifies malicious content.
    1. In the Max Buffer Size field, type the number of bytes to buffer.
    2. In the Max Buffer time field, type the number of seconds to retain response data in the buffer.
    3. For the Reset on Failure field, retain the default value Enabled to send a TCP reset if the server fails.
    4. For each type of content that you want to exclude from analysis, click Add new entry and then select a type from the list.
      The All-Images type is on the list by default because images are not scanned.
    5. Click Finished.
      The popup screen closes.
    6. Click Save.
      The popup screen closes. The visual policy editor displays.
The per-request policy might now include items that look up the URL category and assign a URL filter. You can add other items to the policy to control access according to your requirements.
A per-request policy goes into effect when you add it to a virtual server.

Configuring a per-request policy to control access to applications

Configure a per-request policy to specify the logic that determines whether to allow access to the applications or application families that are supported by Secure Web Gateway (SWG).
Note: The Application Lookup and Application Filter Assign policy items are supported for use in an SWG forward proxy configuration only.
Note: This task provides the steps for adding items to control web traffic based on the application name or application family or based on an application filter. It does not specify a complete per-request policy.
  1. On the Main tab, click Access Policy > Per-Request Policies .
    The Per-Request Policies screen opens.
  2. In the Access Policy column for the per-request policy that you want to update, click the Edit link.
    The visual policy editor opens in another tab.
  3. Add an Application Lookup item to the policy.
    1. Click the (+) icon anywhere in the per-request policy to add a new item.
      A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
    2. Type app in the Search field, select Application Lookup, and click Add Item.
      A Properties popup screen opens.
    3. Click Save.
      The Properties screen closes. The visual policy editor displays. A single branch, fallback, follows the Application Lookup item.
  4. To branch by application family or application name, add branch rules to the Application Lookup item.
    1. Click the name of the application lookup item.
      A Properties popup screen displays.
    2. Click the Branch Rule tab.
    3. Click Add Branch Rule.
      A new entry with Name and Expression settings displays.
    4. Click the change link in the new entry.
      A popup screen opens.
    5. Click the Add Expression button.
      Settings are displayed.
    6. For Agent Sel, select Application Lookup.
    7. For Condition select Application Family or Application Name.
    1. From the list, Application Family is or Application Name is, select a family or name.
    1. Click Add Expression.
      The expression displays.
    2. Continue adding branches and when you are done, click Finished.
      The popup screen closes. The Branch Rules popup screen displays.
    3. Click Save.
      The visual policy editor displays.
    Newly created branches follow the Application Lookup item.
  5. To apply an application filter to the request, add an Application Filter Assign item on a branch somewhere after the Application Lookup item.
    To configure the Application Filter Assign item, you select an application filter from a list.
To put the per-request policy into effect, add it to the virtual server.
Important: To support application filtering, classification must be enabled on the virtual server.

Configuring a per-request policy to branch by group or class

Add a group or class lookup to a per-request policy when you want to branch by user group or class.
Note: The access policy must be configured to populate session variables for a group or class lookup to succeed. This task provides the steps for adding items to control web traffic based on the URL category. It does not specify a complete per-request policy.
  1. On the Main tab, click Access Policy > Per-Request Policies .
    The Per-Request Policies screen opens.
  2. In the Access Policy column for the per-request policy that you want to update, click the Edit link.
    The visual policy editor opens in another tab.
  3. On a policy branch, click the (+) icon to add an item to the policy.
    A small set of actions are provided for building a per-request policy.
    A popup screen displays actions on tabs, such as General Purpose and Authentication, and provides a search field.
  4. On the Authentication tab, select an option: AD Group Lookup, LDAP Group Lookup, or RADIUS Class Lookup to the per-request policy.
  5. Click Add Item.
    A properties popup screen opens.
  6. Click the Branch Rules tab.
  7. To edit an expression, click the change link.
    An additional popup screen opens, displaying the Simple tab.
  8. Edit the default simple expression to specify a group or class that is used in your environment.
    In an LDAP Group Lookup item, the default simple expression is User is a member of CN=MY_GROUP, CN=USERS, CN=MY_DOMAIN. You can use the simple expression editor to replace the default values.
  9. Click Finished.
    The popup screen closes.
  10. Click Save.
    The popup screen closes. The visual policy editor displays.
A per-request policy goes into effect when you add it to a virtual server.

Per-request policy items that read session variables

This table lists per-request policy items that read session variables and lists the access policy items that populate the variables.

Per-request policy item Session variable Access policy item
AD Group Lookup session.ad.last.attr.primaryGroupID AD Query
LDAP Group Lookup session.ldap.last.attr.memberOf LDAP Query
LocalDB Group Lookup session.localdb.groups
Note: This session variable is a default in the expression for LocalDB Group Lookup; any session variable in the expression must match the session variable used in the Local Database action in the access policy.
Local Database
RADIUS Class Lookup session.radius.last.attr.class RADIUS Auth

Per-request policy items for APM and LTM reverse proxy

The table specifies Secure Web Gateway (SWG) support for per-request policy items in an APM® and LTM®reverse proxy configuration.

Per-request policy item Supported with APM and LTM in reverse proxy
Protocol Lookup No
SSL Intercept Set No
SSL Bypass Set No
Response Analytics No
Application Lookup No
Application Filter Assign No
Category Lookup Yes, provided that the input type is not subject.cn
URL Filter Assign Yes
HTTP Headers Yes
Logging Yes
Dynamic Date Time Yes
AD Group Lookup Yes
LDAP Group Lookup Yes
LocalDB Group Lookup Yes
RADIUS Class Lookup Yes

About per-request policies and the Apply Access Policy link

The Apply Access Policy link has not effect on a per-request policy. Conversely, updates made to a per-request policy do not affect the state of the Apply Access Policy link.

About how to trigger URL request event logging

Unless a per-request policy includes and executes a Category Lookup item, URL request event logging does not occur.

About macros and per-request policies

Macros are not supported for per-request policies.

About Safe Search and supported search engines

Note: Safe Search is supported only on a BIG-IP® system with an SWG subscription.

Safe Search is a search engine feature that can prevent offensive content and images from showing up in search results. Safe Search can also protect video searches on Google, Bing, and Yahoo search engines.

Safe Search can be enabled in a per-request policy using the Category Lookup item. Secure Web Gateway (SWG) with Safe Search enabled supports these search engines: Ask, Bing, DuckDuckGo, Google, Lycos, and Yahoo. Some search engines, such as Google and Yahoo, use SSL by default; in this case, Safe Search works only when SWG is configured with SSL forward proxy.

Note: For Safe Search filtering to work correctly, URLs for the supported search engine sites must not be added to a custom category. The search engine's domain must remain categorized in the Search Engines and Portals URL category.

Per-flow variables

Per-flow variables exist only while a per-request policy runs. The table lists per-flow variables and their values.

Name Value
perflow.agent_ending.result 0 (success) or 1 (failure).
perflow.application_lookup.result.families Comma-separated list of application families.
perflow.application_filter_lookup.result.action 0 (reject) or 1 (allow).
perflow.application_lookup.result.effective_application Name of the application that is ultimately used.
perflow.application_lookup.result.effective_family Name of the application family that is ultimately used.
perflow.application_lookup.result.names Comma-separated list of application names.
perflow.application_lookup.result.primary_application Name of the application that SWG determines is the primary one.
perflow.application_lookup.result.primary_family Name of the application family that SWG determines is the primary one. (An application might fit into more than one application family.)
perflow.bypass_lookup.result.ssl 0 (http) or 1 (https).
perflow.category_lookup.failure 0 (success) or 1 (server failure).
perflow.category_lookup.result.categories Comma-separated list of categories.
perflow.category_lookup.result.customcategory Unique number that identifies a custom category; used internally.
perflow.category_lookup.result.effective_category Name of the category that is ultimately used.
perflow.category_lookup.result.filter_name Name of the URL filter.
perflow.category_lookup.result.hostname Host name retrieved from SSL input.
perflow.category_lookup.result.numcategories Integer. Total number of categories in the comma-separated list of categories.
perflow.category_lookup.result.primarycategory Name of the category that SWG determines is the primary one. (A URL might fit into more than one category, such as news and sports.)
perflow.category_lookup.result.url Requested URL.
perflow.protocol_lookup.result http or https. Defaults to https.
perflow.response_analytics.failure 0 (success) or 1 (server failure).
perflow.session.id Session id.
perflow.ssl_bypass_set 0 (bypass) or 1 (intercept). SSL Bypass Set and SSL Intercept Set items update this value.
perflow.ssl.bypass_default 0 (bypass) or 1 (intercept). Specified in the client SSL profile, used when SSL Bypass Set and SSL Intercept Set items not included in per-request policy.
perflow.urlfilter_lookup.result.action 0 (reject) or 1 (allow).
perflow.username User name.

About per-request policy items

When configuring a per-request policy, a few access policy items are available for inclusion in the policy. Most per-request policy items are unique to a per-request policy.

About Protocol Lookup

A Protocol Lookup item determines whether the protocol of the request is HTTP or HTTPS. It provides two default branches: HTTPS and fallback. Use the Protocol Lookup item early in a per-request policy to process HTTPS traffic before processing HTTP traffic.

About SSL Bypass Set

The SSL Bypass Set item provides a read-only element, Action, that specifies the Bypass option.

Note: For an SSL Bypass Set item to be effective, the client and server SSL profiles on the virtual server must enable SSL forward proxy and SSL forward proxy bypass; the client SSL profile must set the default bypass action to Intercept; and the SSL Bypass Set item must occur in the policy before any items that process HTTP traffic.

About AD Group Lookup

An AD Group Lookup item can branch based on Active Directory group. The item provides one default advanced branch rule expression, expr { [mcget {session.ad.last.attr.primaryGroupID}] == 100 }, as an example.

A branch rule expression can include any populated session variable, such as session.ad.last.attr.primaryGroupID, session.ad.last.attrmemberOf, session.ad.last.attr.lastLogon, session.ad.last.attr.groupType, session.ad.last.attr.member, and so on. As an example, expr { [mcget {session.ad.last.attr.memberOf}] contains "CN=Administrators" is a valid expression.

Note: An AD Query action in the access policy can populate the session variables.

About LDAP Group Lookup

An LDAP Group Lookup item compares a specified string against the session.ldap.last.attr.memberOf session variable. The specified string is configurable in a branch rule. The default simple branch rule expression is User is a member of CN=MY_GROUP, CN=USERS, CN=MY_DOMAIN ; the values MY_GROUP, USERS, MY_DOMAIN, must be replaced with values used in the LDAP group configuration at the user site.

Note: An LDAP Query action is required in the access policy to populate the session variable.

About LocalDB Group Lookup

A per-request policy LocalDB Group Lookup item compares a specified string against a specified session variable.

The string is specified in a branch rule of the LocalDB Group Lookup item. The default simple branch rule expression is User is a member of MY_GROUP. The default advanced rule expression is expression is expr { [mcget {session.localdb.groups}] contains "MY_GROUP" }. In either the simple or the advanced rule, the variable, MY_GROUP, must be replaced with a valid group name.

The session variable must initially be specified and populated by a Local Database action in the access policy. A Local Database action reads groups from a local database instance into a user-specified session variable. It can be session.localdb.groups (used by default in the LocalDB Group Lookup advanced rule expression) or any other name. The same session variable name must be used in the Local Database action and the LocalDB Group Lookup advanced rule expression.

About RADIUS Class Lookup

The RADIUS Class Lookup access policy item compares a user-specified class name against the session.radius.last.attr.class session variable. The specified class name is configurable in a branch rule.

The default simple branch rule expression is RADIUS Class attribute contains MY_CLASS . The variable MY_CLASS must be replaced with the name of an actual class.

Note: A RADIUS Acct or RADIUS Auth action is required in the access policy to populate the session variable.

About Dynamic Date Time

The Dynamic Date Time action enables branching based on the day, date, or time on the server. It provides two default branch rules:

Weekend
Defined as Saturday and Sunday.
Business Hours
Defined as 8:00am to 5:00pm.

The Dynamic Date Time action provides these conditions for defining branch rules.

Time From
Specifies a time of day. The condition is true at or after the specified time.
Time To
Specifies a time of day. This condition is true before or at the specified time.
Date From
Specifies a date. This condition is true at or after the specified date.
Date To
Specifies a date. This condition is true before or at the specified date
Day of Week
Specifies a day. The condition is true for the entire day (local time zone).
Day of Month
Specifies the numeric day of month. This condition is true for this day every month (local time zone).

About SSL Intercept Set

The SSL Intercept Set item provides a read-only element, Action, that specifies the Intercept option.

Note: For an SSL Intercept Set item to be effective, the client and server SSL profiles on the virtual server must enable SSL forward proxy and SSL forward proxy bypass; the client SSL profile must set the default bypass action to Intercept; and the SSL Intercept Set item must occur in the policy before any items that process HTTP traffic.

About the Logging action

The Logging action can be used in an access policy or in a per-request policy. In an access policy, the Logging action adds logging for session variables to the access policy. In a per-request policy, the Logging action can add logging for both session variables and per flow variables to the per-request policy.

This action is useful for tracing the variables that are created for a specific category, or in a specific branch.

Note: A session variable might or might not exist at the time of logging; depending on the result of the access policy branch, or results of processing the access policy.

The Logging action provides these configuration elements and options:

Log Message
For an access policy, specifies text to add to the log file. For a per-request policy, specifies the message text and the session and perflow variables to add to the message. Complete variable names must be typed. Wildcards are not supported for per-request policies. An example log message for a per-request policy follows. 
The system found this URL %{perflow.category_lookup.result.url} in these categories %{perflow.category_lookup.result.categories} and placed it into this category %{perflow.category_lookup.result.primarycategory}.
An HTTPS request was made to this host %{perflow.category_lookup.result.hostname}; the per-request policy set SSL bypass to %{perflow.ssl_bypass_set}.
Requests from this platform %{session.client.platform} were made during this session %{perflow.session.id}.
Session Variables
Specifies a session variable from a list of predefined session variables or a custom session variable.
Note: This option is available only when adding the Logging action to an access policy.

About Category Lookup

A Category Lookup item looks up URL categories for a request and obtains a web response page.

The Category Lookup item provides these elements and options.

Categorization Input
The list specifies these options:
  • Use HTTP URI (cannot be used for SSL Bypass decisions): For HTTP traffic, this option specifies performing a URL-based lookup. When selected, on a BIG-IP® system with an SWG subscription the SafeSearch Mode setting displays.
  • Use SNI in Client Hello (if SNI is not available, use Subject.CN): For HTTPS traffic, this option specifies performing a host-based lookup.
  • Use Subject.CN in Server Cert: For HTTPS traffic, this option specifies performing a host-based lookup.
SafeSearch Mode
The options are Enabled (default) and Disabled. When enabled, SWG enables Safe Search for supported search engines.
Note: SafeSearch is available only with an SWG subscription.
Category Lookup Type
Select the category types in which to search for the requested URL. On a BIG-IP® system with an SWG subscription, options are:
  • Select one from Custom categories first, then standard categories if not found
  • Always process full list of both custom and standard categories
  • Process standard categories only
On a BIG-IP® system without an SWG subscription, the available option is Process custom categories only. Depending on the selection, the Category Lookup Type item looks through custom categories or standard categories or both, and compiles a list of one or more categories from them. The list is available for subsequent processing by the URL Filter Assign item.
Reset on Failure
When enabled, specifies that SWG send a TCP reset to the client in the event of a server failure.

About Response Analytics

A Response Analytics item inspects a web response page for malicious embedded contents. Response Analytics must be preceded by a Category Lookup item because it obtains a web response page.

Note: Response Analytics works only on a BIG-IP® system with an SWG subscription.

Response Analytics provides these elements and options.

Max Buffer Size
Specifies the maximum amount of response data (in bytes) to collect before sending it for content scanning. The system sends the content for analysis when the buffer reaches this size or when the buffer contains all of the response content. Otherwise, the system retains the response data in the buffer.
Max Buffer Time
Specifies the maximum amount of time (in seconds) for buffering and analyzing response data. If the time elapses at any point in this process, the agent sets the perflow.response_analytics.failure variable to 1 (which indicates an ANTserver failure) and discards the response data.
Reset on Failure
When enabled, specifies that SWG send a TCP reset to the client in the event of an ANTserver failure. If disabled and an ANTserver failure occurs, SWG logs all perflow variables and provides the SWG block page to the client.
Exclude Types
Specifies one entry for each type of content to be excluded from content analysis. Images, the All-Images type, do not get analyzed.

About URL Filter Assign

A URL Filter Assign item determines whether to block or allow a request. A Category Lookup item must precede URL Filter Assign to provide categories. The URL Filter Assign item looks up the filter action for each category found for the request. If any filter action is set as Block, the request is blocked. The URL filter item also uses the analysis from the Response Analytics item, if used, to determine whether to block or allow the request.

A URL Filter Assign item provides the URL Filter element, a list of filters from which to select.

Note: A Category Lookup item must precede the URL Filter Assign item.

About Application Lookup

An Application Lookup item obtains the name of the application that is being requested and looks up the application family that matches it. By default, this item has a fallback branch only.

Application Lookup can be used to branch by application family or by application name; branch rules are required to do this. If an Application Filter Assign item is included in the per-request policy, an Application Lookup must complete before it.

About Application Filter Assign

An Application Filter Assign item matches an application or application family against an application filter. Application Filter Assign provides one configuration element. The Application Filter element specifies the application filter to use in determining whether to block access to an application or allow it. The Application Filter Assign item exits on the Allow branch if the filter action specifies allow. Otherwise, Application Filter Assign exits on the fallback branch.

Important: To supply input for the Application Filter Assign agent, an Application Lookup item must run in the per-request policy sometime prior to it.

About HTTP Headers

An HTTP Headers action supports modifying an outgoing HTTP request to a back-end server. The action supports manipulation of HTTP and cookie headers being sent to back-end servers.

Important: The HTTP Headers item cannot manipulate HTTP cookies in outgoing HTTP requests to any portal access application.

The HTTP Headers item provides these configuration options and elements.

An entry in the HTTP Header Modify table includes these elements.

Header Operation
Specifies insert, append, replace, or remove.
Header Name
Specifies the header name on which to operate.
Header Value
Specifies the value on which to operate.
Note: Any per-flow or session variable can be used as a header value, for example, %{session.user.clientip} or %{perflow.session.id}.
Header Delimiter
Specifies the separator to use when appending a header.

An entry in the HTTP Cookie Modify table includes these elements.

Cookie Operation
Specifies update or delete.
Note: When update is selected and a cookie that matches the name and value does not exist, HTTP Header adds the specified cookie.
Cookie Name
Specifies the name to match.
Cookie Value
Specifies the value to match when deleting a cookie or the new value to set when updating a cookie.
Note: Any per-flow or session variable can be used as a cookie value.

About per-request policy endings

An ending provides a result for a per-request policy branch. An ending for a per-request policy branch is one of two types.

Allow
Allows the user to continue to the requested URL.
Reject
Blocks the user from continuing and triggers the access profile Logout screen.

Customizing messages for the per-request policy Reject ending

You need an access profile configured.
Customize the messages to display when a per-request policy terminates on a Reject ending. When this happens, the per-request policy triggers the access profile Logout screen.
  1. On the Main tab, click Access Policy > Customization > General .
    The Customization tool appears in General Customization view, displaying Form Factor: Full/Mobile Browser settings.
  2. In the left pane, click the Text tab.
    A navigation tree displays in the left pane.
  3. Expand the Access Profiles folder.
    Folders for access profiles that are configured on the BIG-IP® system in the current partition display.
  4. Expand the folder for access profile that you want to update.
    Folders for access profile objects display.
  5. Expand the Logout folder for the access profile.
    The General setting displays in the folder.
  6. Click General.
    Message settings display in the right pane.
  7. In the right pane, update values.
  8. On the menu bar, click Save.
  9. Click the Apply Access Policy link to apply and activate the changes to the access policy.
  10. On the list of access profiles to apply, verify that the access profile that you updated is selected.
  11. Click the Apply Access Policy button.

Exporting and importing a per-request policy across BIG-IP systems

Export a per-request policy from one BIG-IP® system and import it on another (at the same product version level) to copy a policy across systems.
Note: Per-request policy import does not support the import of custom categories or the URLs defined for them. Before you import a per-request policy from one BIG-IP system to another BIG-IP system, you must first list any custom categories configured on the source system and make sure you have the same custom categories on the target system. Otherwise, import will fail.
  1. On the Main tab, click Access Policy > Per-Request Policies .
    The Per-Request Policies screen opens.
  2. Click the link in the Export column for the policy that you want to export.
    A file downloads.
  3. Note the list of custom categories:
    1. Click Access Policy > Secure Web Gateway > URL Categories .
    2. Expand the Custom Categories list.
  4. Log in to the Configuration utility on the BIG-IP system where you want to import the per-request policy.
  5. Verify that the custom categories that exist on the other BIG-IP system also exist on this BIG-IP system:
    1. Click Access Policy > Secure Web Gateway > URL Categories .
    2. Expand the Custom Categories list.
    3. Create any additional custom categories needed to match the list on the other BIG-IP system.
      The import process does not add URLs to custom categories. To include the URLs defined for a custom category on the source system, you can add them to the target system now or wait until after you import the per-request policy.
  6. On the Main tab, click Access Policy > Per-Request Policies .
    The Per-Request Policies screen opens.
  7. Click Import.
    An Import Policy screen displays.
  8. In New Policy Name, type a name.
  9. For Config File Upload, click Browse, locate and select the file downloaded from the other BIG-IP system.
  10. To reuse objects already existing on this BIG-IP system, select the Reuse Existing Objects check box.
  11. Click Import.
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information