A plan to deploy Websense Content Gateway as a proxy in your network involves more than physical site requirements like plant size, the power and cooling requirements for the hardware, available rack space, and network connectivity. You should also consider some of the following issues:
Websense Content Gateway is used in either an explicit or transparent proxy deployment. With an explicit proxy deployment, client software is configured to send a request for Internet content directly to Websense Content Gateway. In a transparent proxy deployment, a client request for Web content is intercepted (usually by a router) and sent to the proxy, and the client is unaware that it is communicating with a proxy.
A Websense Content Gateway deployment can scale from a single node to multiple nodes to form management cluster. With management clustering, all the nodes in a cluster share configuration information. A configuration change on one node is automatically made in all other nodes.
When SSL Manager is enabled to perform HTTPS content inspection, SLL configuration information can also be propagated around the cluster, however it uses a different mechanism that requires separate configuration.
See Clusters in
Content Gateway Manager online Help for information about configuring proxy clusters.
When enabled, the IP spoofing feature directs the proxy to use the client IP address when establishing a connection to an origin server, rather than the proxy's IP address. With this option, a request appears to be from the client, not the proxy. IP spoofing is supported only in transparent proxy deployments. You should note that if IP spoofing is implemented, the client IP address is used for
all HTTP and HTTPS requests in transparent proxy deployments.
You might want to implement this feature, for example, if an upstream network device is used to log HTTP/S traffic, perform authentication, or access controls based on the client IP address.
Authentication is the process of verifying a user via a username and password. User authentication may be configured on Websense Content Gateway. User identification is the process of identifying a user based on the client IP address. TRITON - Web Security offers a robust set of user identification agents.
Websense Content Gateway can be configured for transparent user authentication -- with Integrated Windows® Authentication (IWA) and Legacy NTLM -- in which case users are not prompted for credentials, or for
prompted (or
manual) authentication, in which case users are required to enter a username and password for network access.
In the manual authentication process, Content Gateway prompts a user for proxy login credentials when that user requests Internet content. After the user enters those credentials, the proxy sends them to a directory server, which validates the data. If the directory server accepts the user's credentials, the proxy delivers the requested content. Otherwise, the user's request is denied.
The issue of proxy authentication is important in a deployment in which multiple proxies are chained. Authentication by the proxy closest to the client is preferred, but may not be possible given a particular network's configuration. Other issues include whether Content Gateway is chained with a third-party proxy and which proxy is designated to perform authentication. See
In a proxy chain for more information.
Content Gateway supports both transparent and prompted authentication for Integrated Windows Authentication and Legacy NTLM. LDAP and RADIUS support prompted authentication.
Content Gateway also supports multiple realm authentication. Multiple realm authentication is for environments that have multiple domains that are essentially isolated for the purposes of user authentication by a lack of mutual inbound and outbound trust relationships. Therefore, users in these domains must be authenticated by a domain controller within their domain. Multiple realm authentication allows distinct authentication rules to be written for each domain, thereby supporting the ability to use multiple authentication methods (IWA, legacy NTLM, LDAP) at the same time.
See Security in the
Content Gateway Manager online Help for detailed information about configuring all these proxy authentication options.
You can configure user identification in TRITON - Web Security rather than user authentication on the proxy. Methods of user identification include the use of Websense transparent identification (XID) agents like Logon Agent or DC Agent, which identify users transparently. Prompted authentication, which requires users to enter login credentials, can also be configured in TRITON - Web Security. See
User Identification in the
TRITON - Web Security Help for more information.
When you use Websense Content Gateway with SSL Manager enabled, HTTPS data can be decrypted, inspected for policy, and then re-encrypted as it travels from the client to the origin server and back. Enabling this feature also means that traffic from the server to the client can be inspected for Web 2.0 and uncategorized sites. The SSL feature includes a complete set of certificate-handling capabilities. See the
Content Gateway Manager online Help for information on managing certificates.
When Content Gateway is configured to handle HTTPS traffic, category bypass settings can be used to specify categories of Web sites for which decryption and inspection are bypassed. You can also maintain a list of hostnames or IP addresses for which SSL decryption is not performed. See
Scanning and SSL Bypass Options in
TRITON - Web Security Help for more information.
Any Websense Content Gateway deployment must be able to handle Web site requests and applications that are not compatible with the proxy or that should bypass the proxy. For example, requests for data from some internal, trusted sites could be configured to bypass the proxy, for system performance reasons. In explicit proxy deployments, a PAC file can be used to list the traffic that is allowed to bypass proxy inspection. In transparent proxy deployments, the proxy must be installed in a way that allows static bypass. See the "Static bypass rules" section of
Transparent Proxy Caching and ARM in
Content Gateway Manager online Help.
The deployment should also be able to manage situations in which key fobs or tokens are used to access the network and for cases of highly coupled client/server Web applications. The type of proxy deployment determines how these situations are handled.
Deployment and Installation Center
