Archive Integration Guide › ICAP Agent › Overview

Overview

The ICAP Agent enables CA DataMinder to integrate with Internet Content Adaptation Protocol (ICAP) clients. This provides CA DataMinder with a further method for controlling HTTP activity such as file uploads and downloads.

Organizations run ICAP clients on proxy servers such as Blue Coat ProxySG and Squid to intercept and offload requests initiated from a browser and the corresponding responses from a Web site.

When the ICAP Agent (technically an ICAP server) receives requests from an ICAP clients, it routes them to CA DataMinder policy engines which can then apply Data In Motion triggers, for example, to block inappropriate uploads.

The diagram below shows an example deployment architecture for the ICAP agent and the information flow for an HTTP request.

ICAP agent example deployment architecture

1. A user attempts to upload a file using HTTP. For example, while using a Webmail application, the user attaches a file to the Webmail.
2. Proxy server and ICAP client: The email is sent using HTTP or HTTPS to the proxy server (2a). The ICAP client (2b) on the proxy server intercepts the request and routes the file to the ICAP agent (3a).
3. ICAP agent and hub: The ICAP agent (3a) passes the file to a Remote PE Connector (3b), which in turn allocates it a policy engine (4).
4. Policy engines: A PE analyzes the file. The outcome of any policy processing (‘block’ or ‘allow’) is routed back via the ICAP agent to the ICAP client.
5. Result of policy processing: These results are routed back to the ICAP client. If the result is:
   • ‘Allow’ (5a), the upload is permitted and the request is processed by the ICAP client.
   • ‘Block’ (5b), the upload is blocked and the ICAP client routes a notification message to the user's browser.
6. CMS: Any resulting events are replicated up to the CMS and stored for subsequent retrieval and reviewing (7).