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 &lt;name&gt;
  [-IPAddress &lt; ip_addr|ipv6_addr&gt;]
  [-port &lt;port&gt;]
        [-vServer &lt;string&gt;]
  [-returnType &lt;returnType&gt;]
  [-httpMethod ( GET | POST )]
  [-hostExpr &lt;string&gt;]
  [-urlStemExpr &lt;string&gt;]
  [-headers &lt;name(value)&gt; ...]
  [-parameters &lt;name(value)&gt; ...]
  [-fullReqExpr &lt;string&gt;]
  [-resultExpr &lt;string&gt;]

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!