A per-request policy must specify the logic that determines how to process URL requests whether they are requests for web access. 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.
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.
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.
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:
For SSL bypass or SSL intercept actions, Access Policy Manager® (APM®) 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).
Unless a per-request policy includes and executes a Category Lookup item, URL request event logging does not occur.
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.
Typically, an access policy verifies endpoint security and authenticates a user before starting an access session. If the user requests access to a sensitive resource after the session is established, you can require additional authentication or revalidation of the credentials for that resource by configuring a per-request policy subroutine.