Classic and advanced policies
Warning:
Classic policy expressions are deprecated from Citrix ADC 12.0 build 56.20 onwards and as an alternative, Citrix recommends you to use Advanced policies. For more information, see Advanced Policies
Classic policies evaluate basic characteristics of traffic and other data. For example, classic policies can identify whether an HTTP request or response contains a particular type of header or URL.
Advanced policies can perform the same type of evaluations as classic policies. In addition, advanced policy infrastructure (PI) enable you to analyze more data (for example, the body of an HTTP request) and to configure more operations in the policy rule (for example, transforming data in the body of a request into an HTTP header).
In addition to assigning a policy an action or profile, you bind the policy to a particular point in the processing associated with the Citrix ADC features. The bind point is one factor that determines when the policy will be evaluated.
Benefits of using advanced policies
Default syntax 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 Citrix ADC features. With advanced policy infrastructure (PI), 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 (PI) supports at the default, override, and virtual server levels.
- Use goto expressions to transfer control to other policies and bind points, as determined by the result of expression evaluation.
- Use special tools such as pattern sets, policy labels, rate limit identifiers, and HTTP callouts, which enable you to configure policies effectively for complex use cases.
Also, the configuration utility extends robust graphical user interface support for advanced policy infrastructure (PI) 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 a 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 Citrix ADC feature to evaluate a piece of traffic or another object. For example, a rule can enable the Citrix ADC 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.”
Advanced policies can use all of the expressions that are available in a classic policy, with the exception of classic expressions for the SSL VPN client. In addition, Advanced policies enable you to configure more complex expressions.
- Bindings. To ensure that the Citrix ADC 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 Citrix ADC 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 Citrix ADC features use policies
The Citrix ADC supports various features that rely on policies for operation. The following table summarizes how the Citrix ADC features use policies.
| Feature Name | Policy Type | How You Use Policies in the Feature |
|---|---|---|
| System | Classic | For the Authentication function, policies contain authentication schemes for different authentication methods. For example, you can configure LDAP and certificate-based authentication schemes. You also configure policies in the Auditing function. |
| DNS | Advanced | To determine how to perform DNS resolution for requests. |
| SSL | Classic and Advanced | To determine when to apply an encryption function and add certificate information to clear text. To provide end-to-end security, after a message is decrypted, the SSL feature re-encrypts clear text and uses SSL to communicate with Web servers. |
| Compression | Classic and Advanced | To determine what type of traffic is compressed. |
| Integrated Caching | Advanced | To determine whether HTTP responses are cacheable. |
| Responder | Advanced | To configure the behavior of the Responder function. |
| Protection Features | Classic | To configure the behavior of the Filter, SureConnect, and Priority Queuing functions. |
| Content Switching | Classic and Advanced | To determine what server or group of servers is responsible for serving responses, based on characteristics of an incoming request. Request characteristics include device type, language, cookies, HTTP method, content type, and associated cache server. |
| AAA - Traffic Management | Classic. Exceptions: Traffic policies support only advanced policy infrastructure (PI)s aand authorization policies support both classic and advanced policy infrastructure (PI). | To check for client-side security before users log in and establish a session. Traffic policies, which determine whether single sign-on (SSO) is required, use only the default syntax. Authorization policies authorize users and groups that access intranet resources through the appliance. |
| Cache Redirection | Classic | To determine whether responses are served from a cache or from an origin server. |
| Rewrite | Advanced | To identify HTTP 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 the purpose of evaluating whether a URL should be transformed. |
| Application Firewall | Classic and Advanced | To identify characteristics of traffic and data that should or should not be admitted through the firewall. |
| Citrix Gateway, Clientless Access function | Advanced | To define rewrite rules for general Web access using the Citrix Gateway. |
| Citrix Gateway | Classic | To determine how the Citrix Gateway performs authentication, authorization, auditing, and other functions. |
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 Citrix ADC 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 Citrix ADC 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 Citrix ADC 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.
About profiles
Some Citrix ADC 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.
Use of actions and profiles in particular features
The following table summarizes the use of actions and profiles in different Citrix ADC features. The table is not exhaustive. For more information about specific uses of actions and profiles for a feature, see the documentation for the feature.
| Feature | Use of an Action | Use of a Profile |
|---|---|---|
| Application firewall | Synonymous with a profile | All application firewall features use profiles to define complex behaviors, including pattern-based learning. You add these profiles to policies. |
| Citrix Gateway | The following features of the Citrix Gateway use actions: Pre-Authentication. Uses Allow and Deny actions. You add these actions to a profile., Authorization. Uses Allow and Deny actions. You add these actions to a policy. TCP Compression. Uses various actions. You add these actions to a policy. | The following features use a profile: Pre-Authentication, Session, Traffic, and Clientless Access. After configuring the profiles, you add them to policies. |
| Rewrite | You configure URL rewrite actions and add them to a policy. | Not used. |
| Integrated Caching | You configure caching and invalidation actions within a policy | Not used. |
| AAA - Traffic Management | You select an authentication type, set an authorization action of ALLOW or DENY, or set auditing to SYSLOG or NSLOG. | You can configure session profiles with a default timeout and authorization action. |
| Protection Features | You configure actions within policies for the following functions: Filter, Compression, Responder, and SureConnect. | Not used. |
| SSL | You configure actions within SSL policies | Not used. |
| System | The action is implied. For the Authentication function, it is either Allow or Deny. For Auditing, it is Auditing On or Auditing Off. | Not used. |
| DNS | The action is implied. It is either Drop Packets or the location of a DNS server. | Not used. |
| SSL Offload | The action is implied. It is based on a policy that you associate with an SSL virtual server or a service. | Not used. |
| Compression | Determine the type of compression to apply to the data | Not used. |
| Content Switching | The action is implied. If a request matches the policy, the request is directed to the virtual server associated with the policy. | Not used. |
| Cache Redirection | The action is implied. If a request matches the policy, the request is directed to the origin server. | Not used. |
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 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 (PI), 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 policy (classic or advanced policies), and specifics of the relevant Citrix ADC feature. For example, classic policies that you configure for the Citrix Gateway have user and group bind points.
For additional information about advanced policy bindings, see Bind policies that use the advanced policies and Configure a policy bank for a virtual server. For additional information about classic policy bindings, see Configure a classic policy.
About evaluation order of policies
For classic policies, policy groups and policies within a group are evaluated in a particular order, depending on the following:
- The bind point for the policy, for example, whether the policy is bound to request-time processing for a virtual server or global response-time processing. For example, at request time, the Citrix ADC evaluates all request-time classic policies before evaluating any virtual server-specific policies.
- The priority level for the policy. For each point in the evaluation process, a priority level that is assigned to a policy determines the order of evaluation relative to other policies that share the same bind point. For example, when the Citrix ADC evaluates a bank of request-time, virtual server-specific policies, it starts with the policy that is assigned to the lowest priority value. In classic policies, priority levels must be unique across all bind points.
For Advanced policies, as with classic policies, the Citrix ADC selects a grouping, or bank, of policies at a particular point in overall processing. Following is the order of evaluation of the basic groupings, or banks, of Advanced policies:
- Request-time global override
- Request-time, virtual server-specific (one bind point per virtual server)
- Request-time global default
- Response-time global override
- Response-time virtual server-specific
- Response-time global default
However, within any of the preceding banks of policies, the order of evaluation is more flexible than in classic policies. Within a policy bank, you can point to the next policy to be evaluated regardless of the priority level, and you can invoke policy banks that belong to other bind points and user-defined policy banks.
Order of evaluation based on traffic flow
As traffic flows through the Citrix ADC and is processed by various features, each feature performs policy evaluation. Whenever a policy matches the traffic, the Citrix ADC stores the action and continues processing until the data is about to leave the Citrix ADC. At that point, the Citrix ADC typically applies all matching actions. Integrated Caching, which only applies a final Cache or NoCache action, is an exception.
Some policies affect the outcome of other policies. Following are examples:
- If a response is served from the integrated cache, some other Citrix ADC features do not process the response or the request that initiated it.
- If the Content Filtering feature prevents a response from being served, no subsequent features evaluate the response.
If the application firewall rejects an incoming request, no other features can process it.