Advanced policy Infrastructure
The advanced policy infrastructure enables you to analyze many pieces of data (for example, the body of an HTTP request) and to configure many operations in the policy rule (for example, transforming data in the body of a request into an HTTP header). You must bind the policy to a particular point in the processing associated with the NetScaler features. The bind point is one factor that determines when the policy will be evaluated.
Benefits of using advanced policies
Advanced policies use a powerful expression language that is built on a class-object model, and they offer several options that enhance your ability to configure the behavior of various NetScaler features. With advanced policy infrastructure, you can do the following:
- Perform fine-grained analyses of network traffic from layers 2 through 7.
- Evaluate any part of the header or body of an HTTP or HTTPS request or response.
- Bind policies to the multiple bind points that the advanced policy infrastructure supports at the default, override, and virtual server levels.
- Use special tools such as pattern sets, policy labels, rate limit identifiers, HTTP callouts, and variables, which enable you to configure policies effectively for complex use cases.
Also, the configuration utility extends robust GUI support for advanced policy infrastructure and expressions and enables users who have limited knowledge of networking protocols to configure policies quickly and easily. The configuration utility also includes a policy evaluation feature for advanced policies. You can use this feature to evaluate an advanced policy and test its behavior before you commit it, thus reducing the risk of configuration errors.
Basic components of an advanced policy
Following are a few characteristics of an Advanced policy:
-
Name. Each policy has a unique name.
-
Rule. The rule is a logical expression that enables the NetScaler feature to evaluate a piece of traffic or another object. For example, a rule can enable the NetScaler to determine whether an HTTP request originated from a particular IP address, or whether a Cache-Control header in an HTTP request has the value “No-Cache.”
-
Bindings. To ensure that the NetScaler can invoke a policy when it is needed, you associate the policy, or bind it, to one or more bind points.
You can bind a policy globally or to a virtual server. For more information, see About policy bindings.
-
An associated action. An action is a separate entity from a policy. Policy evaluation ultimately results in the NetScaler performing an action.
For example, a policy in the integrated cache can identify HTTP requests for .gif or .jpeg files. An action that you associate with this policy determines that the responses to these types of requests are served from the cache.
For some features, you configure actions as part of a more complex set of instructions known as a profile.
How different NetScaler features use policies
The NetScaler supports various features that rely on policies for operation. The following table summarizes how the NetScaler features use policies.
| Feature name | How you use policies in the feature |
|---|---|
| Rewrite | To identify the data that you want to modify before serving. The policies provide rules for modifying the data. For example, you can modify HTTP data to redirect a request to a new home page, or a new server, or a selected server based on the address of the incoming request, or you can modify the data to mask server information in a response for security purposes. The URL Transformer function identifies URLs in HTTP transactions and text files for evaluating whether a URL must be transformed. |
| Responder | To configure the behavior of the Responder function. A responder policy is based on a rule, which consists of one or more expressions. The rule is associated with an action, which is performed if a request matches the rule. |
| Content Switching | To determine what server or group of servers is responsible for serving responses, based on the characteristics of an incoming request. Request characteristics include device type, language, cookies, HTTP method, content type, and associated cache server. |
| Cache Redirection | To determine whether responses are served from a cache or from an origin server. |
| Compression Control | To determine what type of traffic must be compressed. |
| DNS | To modify various portions of DNS requests and responses |
| VPN clientless access | To determine how the NetScaler Gateway performs authentication, authorization, auditing, and other functions, and to define rewrite rules for general Web access using the NetScaler Gateway. |
| Cache | To determine whether to serve a response from the cache or the origin server. |
| URL Transform Policy | To select the requests and responses that the NetScaler must transform by using the URL transformation profile. |
| Application Firewall Policy | To assign different filtering rules to different types of web content. |
| Authorization | To provide access to the requested content without exposing unnecessary details about the website’s actual configuration. |
| TM traffic | To set the characteristics (such as connection timeout, single sign-on, and initiating logout) of application traffic at run time. |
| TM session | To customize user sessions after the user logs on to the Authorization, Authorization, and Accounting virtual server. |
| SSL Policies | To define a control or a data action to be performed on requests. SSL policies can therefore be categorized as control policies and data policies. A control policy uses a control action, such as forcing client authentication. A data policy uses a data action, such as inserting some data into the request. |
| Autoscale | To scale the number of virtual servers up or down seamlessly and automatically according to the defined conditions. |
| AppFlow | To allow NetScaler to export flow data to collection tools, often to be used for network or security analysis. |
| Content optimization | To reduce transaction times between the clients and the servers, and reduce bandwidth consumption. Also to enhance server performance by offloading some tasks and making others more efficient. |
| Spillover | To use a NetScaler rule to specify the conditions for spillover to occur. The rules give you the flexibility to configure spillover for various operational conditions. |
| ICA | To dynamically generate an ICAP request, receive the ICAP response, and log content inspection data. |
| VPN Session | On a NetScaler Gateway, to configure Endpoint Analysis (EPA) to check if a user device meets certain security requirements and accordingly allow access of internal resources to the user. |
| VPN Traffic | On a NetScaler Gateway, to configure Endpoint Analysis (EPA) to check if a user device meets certain security requirements and accordingly allow access of internal resources to the user. |
| syslog | To define which messages to log to the specified syslog server. |
| nslog | To define which messages to log to the specified nslog server. |
| Video Optimization Detection | To create a user-defined video optimization detection policy label, to which you can bind detection policies. A policy label is a tool for evaluating a set of policies in a specified order. By using a policy label, you can configure the video optimization feature to choose the next policy, invoke a different policy label, or terminate a policy evaluation completely by looking at whether the previous policy evaluated to TRUE or FALSE. |
| Tunneling | To define the type of compression to be used for the tunneled traffic. |
| Content Inspection | To specify requests that the NetScaler ADC intercepts and runs the specified action. |
| VPN URL | To create a bookmark link to an external or internal resource that appears on the Access Interface, according to type, as a website link or file share link. |
| Bot | To create a user-defined bot policy label, to which you can bind policies. A policy label is a tool for evaluating a set of policies in a specified order. By using a policy label, you can configure the responder feature to choose the next policy, invoke a different policy label, or terminate a policy evaluation completely by looking at whether the previous policy evaluated to TRUE or FALSE. |
| VPN intranet application policy | To define intranet applications to be made accessible through a NetScaler Gateway. |
| SmartAccess | To create an ICA access profile that specifies the status of the features(Default or Disabled). |
| Load Balancing | To define how to distribute the client connections among the load-balanced servers that it manages. |
About actions and profiles
Policies do not themselves take action on data. Policies provide read-only logic for evaluating traffic. To enable a feature to perform an operation based on a policy evaluation, you configure actions or profiles and associate them with policies.
Note:
Actions and profiles are specific to particular features. For information about assigning actions and profiles to features, see the documentation for the individual features.
About actions
Actions are steps that the NetScaler takes, depending on the evaluation of the expression in the policy. For example, if an expression in a policy matches a particular source IP address in a request, the action that is associated with this policy determines whether the connection is permitted.
The types of actions that the NetScaler can take are feature specific. For example, in Rewrite, actions can replace text in a request, change the destination URL for a request, and so on. In Integrated Caching, actions determine whether HTTP responses are served from the cache or an origin server.
In some NetScaler features actions are predefined, and in others they are configurable. In some cases (for example, Rewrite), you configure the actions using the same types of expressions that you use to configure the associated policy rule.
Note:
Not all combinations of feature, protocol, direction, and entity are valid.
About profiles
Some NetScaler features enable you to associate profiles, or both actions and profiles, with a policy. A profile is a collection of settings that enable the feature to perform a complex function. For example, in the application firewall, a profile for XML data can perform multiple screening operations, such as examining the data for illegal XML syntax or evidence of SQL injection.
About policy bindings
A policy is associated with, or bound to an entity that enables the policy to be invoked. For example, you can bind a policy to request-time evaluation that applies to all virtual servers. A collection of policies that are bound to a particular bind point constitutes a policy bank.
Following is an overview of the different types of bind points for a policy:
- Request time global. A policy can be available to all components in a feature at request time.
- Response time global. A policy can be available to all components in a feature at response time.
- Request time, virtual server-specific. A policy can be bound to request-time processing for a particular virtual server. For example, you can bind a request-time policy to a cache redirection virtual server to ensure that particular requests are forwarded to a load balancing virtual server for the cache, and other requests are sent to a load balancing virtual server for the origin.
- Response time, virtual server-specific. A policy can also be bound to response-time processing for a particular virtual server.
- User-defined policy label. For advanced policy infrastructure, you can configure custom groupings of policies (policy banks) by defining a policy label and collecting a set of related policies under the policy label.
- Other bind points. The availability of additional bind points depends on type of advanced policy, and the specifics of the relevant NetScaler feature.
For additional information about advanced policy bindings, see Bind policies that use the advanced policies topic.
About evaluation order of policies
The features in the NetScaler are processed in a certain order, which includes evaluating the policies for the feature and performing the actions selected. For more information, see Packet flow.
At any one point in message processing, policy evaluation is performed depending on the combination of the following:
- Protocol (such HTTP, SIP TCP, or Diameter)
- Direction (request or response)
- Feature (such as Rewrite, Responder, or Bot)
The combinations cannot be mixed up. Policies are evaluated in groups of policies called banks (also called policy labels or bind points) in the following order:
- Global override
- Specific LB virtual server used
- If any specific CS virtual server used
- Global default
Within a bank, policies are evaluated from the lowest numbered priority to the highest. If a policy rule evaluates to false, evaluation automatically goes to the next higher numbered priority in the same bank. If there are no policy rules in the same bank, then the evaluation falls to the first policy of the next bank in the order. If there are no more policies, then policy evaluation ends. If a policy rule evaluates to true, the corresponding action or profile is remembered for possible later execution.
If the policy is evaluated to true, then the “gotoPriorityExpression” value is checked. If “gotoPriorityExpression” is “END” then policy evaluation stops. If “NEXT” then the next policy (as described above) gets evaluated. If it is an expression then that expression is evaluated and the policy with that priority is selected next.
Note
The default “gotoPriorityExpression” value except for policy labels is “END”. However, for some features that can run all the actions, we recommend you to explicitly specify the “gotoPriorityExpression” value.
Once policy evaluation stops, the feature runs the ordered list of actions or profiles. The features either run all actions (for example Rewrite) or run one action (for example, Responder or Bot). If more than one action or profile is associated with a feature that can only run one, the standard is to run the last one. If there are no actions or profiles selected, then the feature performs its default action.
Order of evaluation based on traffic flow
Some policies affect the outcome of other policies. Following are examples:
-
If a response is served from the integrated cache, some other NetScaler features do not process the response or the request that initiated it.
-
If the application firewall rejects an incoming request, no other features can process it.
-
Most actions that are performed by Responder stops further processing.
-
The Drop and Reset actions performed by Rewrite stops further processing.