Post to Twitter
Entity Templates
An entity template simplifies configuration by providing a set of configured defaults for a policy, service, action, or other configuration entity. After you create an entity template, it can be reused with specific instances of entities of the same type. For example, an entity template created for Load Balancing, can be used to create the same load balancing configuration on the same load balancer, or can be used on a different NetScaler or NetScalers to create the same load balancing configuration.
Entity Templates are most helpful when you have built your configuration for an entity such as load balancing and want to duplicate it across the organization's load balancers without having to re-type all of the configuration commands. In fact, the entity template manager, will allow you to prompt for certain configuration parameters to be input by the user, such as IP Address and port number, at the time of import, which might be specific to a certain locality.
Application Templates
The NetScaler includes the ability to create and manage application templates that provide the administrator a way to configure the NetScaler to handle application-specific traffic without directly configuring NetScaler entities. An application template is a reusable bundle of application's configuration information and can be exported after creation for use on other NetScalers. Also, these templates can be created once and then re-used across multiple NetScalers.
Application vs. Entity Templates
Entity Templates simplify configuration by providing a set of configured default for a specific configuration entity, such as load balancing, rewrite or content switching.
Application Templates simplify configuration by providing configuration details for all entities for an Application, such as Sharepoint, SAP, Oracle, or other web based applications. Application Templates are more comprehensive and contain configuration details for caching, compression, load balancing, ssl offload, rewrite, filtering, responder and application firewall. For one application you might have several policies in each of these categories that are saved into an Application Template.
Both Entity and Application Templates can be exported and imported for ease of use across different NetScalers. All of the configuration policies, including all expressions, pattern sets and policy labels are exported with the Entity or Application Template - once you define your policies, you don't have to define them again.
Watch how easy this is:
Tap into the power of AppExpert!
HTTP Callouts
New in NetScaler 9.0 is the ability to perform a callout using HTTP to an external server. An HTTP Callout is a means to process incoming packets on the NetScaler using an external service that can be a virtual server on the NetScaler itself, a back-end server, or an third party service.
Traditionally, the NetScaler used to verify these packets internally using in-built policies but with specialized services being available for validation, they can be integrated with the NetScaler using this feature.
An HTTP callout will consist of a NetScaler policy expression that can send a simple HTTP request to an external service, wait for the response and then parse the response to produce a simple result. The result will then be used like any other policy expression evaluation result.
The HTTP callout expression:
SYS.HTTP_CALLOUT(<name of HTTP Callout>)
To define the HTTP callout:
set policy httpCallout <name>
[-IPAddress < ip_addr|ipv6_addr>]
[-port <port>]
[-vServer <string>]
[-returnType <returnType>]
[-httpMethod ( GET | POST )]
[-hostExpr <string>]
[-urlStemExpr <string>]
[-headers <name(value)> ...]
[-parameters <name(value)> ...]
[-fullReqExpr <string>]
[-resultExpr <string>]
Where:
-returnType must be one of TEXT, NUM or BOOL.
-IPAddress IP address of the server to which callout is made
-port Port of the server to which callout is made
-vserver must be one of the vservers added using the "add lb/cs/cr vserver" command. The service type of the vserver must be HTTP.
-httpMethod could be GET or POST.
-hostExpr Complex PI string expression for value of the Host header.
-urlStemExpr Complex PI string expression for generating the URL stem.
-headers Every header name must have a corresponding value. These headers will be inserted in the request. Header name is string. Header values are Complex PI Expressions.
-parameters Every parameter name must have a corresponding value. These parameter names are put in the URL query if the request has a GET method or they are put in the body if the request has a POST method. One must not rely on the order in which the parameters are inserted. Parameter name is a string. The parameter values can be computed using Complex PI String expressions. The parameter values will be URL encoded.
-fullReqExpr A complex PI String expressions computes the entire request. It is the user's responsibility to provide a well formed and sane HTTP request. The system will not do any sanity checking. If full request is specified then none of the other arguments can be specified.
HTTP callouts are available with HTTP or TCP Content Switching, Responder and Rewrite functionality.
The basic communication flow for HTTP callout is:
1. User sends request
2. Policy sends HTTP request to an external service
3. Result used like any other policy evaluation result
4. Available for multiple features
HTTP Callout Deployment Scenarios
The examples in this section illustrate how to use HTTP callouts to perform various tasks. In all cases, the NetScaler performs a callout to an external server where a callout agent is configured to respond to the request from the NetScaler based on the data that is present on the external server.
This section describes how to configure HTTP callouts in the following scenarios:
1. Filter clients based on an IP blacklist.
2. Fetch and update content on the fly using Edge Side Includes (ESI) markup language.
3. Authenticate users and control access to resources.
4. Filter Outlook Web Access (OWA) spam.
Filtering clients based on an IP blacklist
HTTP callouts can be used to block requests from clients that are blacklisted by the administrator. This list of clients can either be a publicly known blacklist or one that is maintained specifically by the administrator or a combination of both.
The source IP address of the incoming client request is checked against the external pre-configured blacklist and based on whether the IP address has been blacklisted or not, the transaction is either blocked by the NetScaler or the NetScaler continues to process the transaction normally.
The HTTP callout feature facilitates this by allowing the NetScaler to communicate with the external server that maintains a database of such blacklisted IP addresses.
The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.
ESI support for fetching and updating content dynamically
Edge Side Includes (ESI) is a markup language for edge-level dynamic Web content assembly. It helps in accelerating dynamic Web-based applications by defining a simple markup language to describe cacheable and non-cacheable Web page components that can be aggregated, assembled, and delivered at the network edge.
Using HTTP callouts on the NetScaler, you can read through the ESI constructs and aggregate or assemble content dynamically.
The following outlines the requirements to implement this configuration:
1. Enable Rewrite on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Rewrite action to replace the ESI content with the callout response body.
4. Bind the Rewrite action to a Rewrite policy.
5. Bind the Rewrite policy globally on the NetScaler.
Access Control and Authentication
In high security environments, it may be mandatory to externally authenticate a user before a resource is accessed by clients. On the NetScaler, you can use HTTP callouts to externally authenticate a user based on supplied credentials. There are different ways that authentication credentials might be supplied; the client could be sending the user name and password in HTTP headers in the request, or, the credentials could be fetched from the URL or the HTTP body.
The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.
OWA-based spam filtering
Spam filtering is the ability to dynamically block emails that are not from a known or trusted source or has inappropriate content. Spam filtering requires business logic that indicates a particular kind of message is a spam.
Using HTTP callouts, you can take out any portion of the incoming message and check with the configured external callout server that has the rules to detect if the message is a legitimate email or spam. In case of a spam email, the sender will not be notified that the email is marked as spam because it will only alert spammers to modify their messages.
The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.
Read about the Citrix Application Switch with Version 9.0 here.
Try the Citrix Application Switch with Version 9.0 here.
Tap into the power of AppExpert!
Not very long ago I published a series on how to become an Application Expert. Citrix NetScaler 9.0 makes it easier with AppExpert Templates. NetScaler AppExpert Templates - introduced in NetScaler 9.0 - provide an application-centric view of the NetScaler system's policy configurations. From a single place within the GUI (AppExpert -> Applications) NetScaler administrators can: 1) Configure the various AppExpert features the NetScaler is fronting, 2) View which NetScaler functional modules (e.g., compression, caching, application firewall) are optimized and active for a given application unit.
Additionally, AppExpert Templates allow you to drill down and see which individual NetScaler policies are active, and what policies are inactive but available, by application component and NetScaler module. From this same view, individual policies can be created, activated and deactivated.
AppExpert Templates can be downloaded, imported, modified and exported AppExpert Templates page of the Citrix Community Website. Administrators can download AppExpert Templates built by Citrix, Citrix Partners and members of the NetScaler community from the Citrix Community Website. These templates are easily imported into any NetScaler running NetScaler 9.0 or higher, jump starting the configuration and deployment process. Templates developed in-house can be easily exported and shared within your organization, or posted back to the Citrix Community Website for others to view and improve.
See the new AppExpert Templates page here!
Tap into the power of AppExpert!
Application Delivery is at the top of the list of any organization's priorities. Keeping up with those priorities requires a move to dynamic application delivery and virtualization. The Citrix NetScaler Application Switch is a powerful step in that direction.
Compressing content at the server level can be done, but is tedious, and with the number of hosted servers on the backend growing proportionally with virtualization, it is better suited to a frontend tool.
As an Application Expert, determining what type of content is compressible vs. that which is not compressible should be at the tip of your tongue, or at least you should be able to reference this post or document. The thing is, while some content types remain compressible/non-compressible across many applications, you might run across an application that requires some content be treated uniquely. For example, the SAP application requires that pdf files should not be compressed when sent back to the clients. Either way, you should know how to dynamically configure rules to accommodate for the applications content. This Compression Deployment Guide shows you how.
Watch this Compression Tip:
Buy the Citrix NetScaler Application Switch here.
Tap into the power of AppExpert.
Moved Document Root
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Usually the Document Root of the web server directly relates to the URL "/". But in some cases the document root should shift to some other directory. The following rules can be used to implement this.
Example : Rewrite the url / to /e/www
Apache rewrite:
RewriteEngine on RewriteRule ^/$ /e/www/ [R]
AppExpert rewrite: (There are two ways to do this)
add responder action act1 redirect '"/e/www/"' -bypassSafetyCheck yes add responder policy pol1 'HTTP.REQ.URL.EQ("/")' act1 bind responder global pol1 100
add responder action act1 redirect '"/e/www"+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.URL.STARTSWITH("/e/www/")' act1 bind responder global pol1 100 END
Tap into the power of AppExpert!