Applies To:Show Versions
- 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
Per-Request Policy Examples for SWG
SSL bypass example
This example is for use in an SSL forward proxy configuration. In it, a 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.
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 Assign or Application Lookup, that inspect the SSL payload. The URL Filter Assign item determines whether to allow, block, or confirm 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.
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.
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.
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.
Category-specific access restrictions
Application lookup and filter example
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.|
Confirm request subroutine example
In this per-request policy example, a subroutine that displays a Confirm Box follows the Confirm branch after the URL Filter Assign item.
Per-request policy with subroutine to present Confirm Box
Additional authentication subroutine example
Per-request policy with subroutine for additional authentication