Using Policy Agents with Reverse Proxy

If your OpenSSO deployment architecture includes a reverse proxy server (as described in Using a Reverse Proxy), you have the option of protecting the content servers by installing a policy agent on the proxy itself, or installing multiple policy agents on the content servers behind the reverse proxy server. The choice is dependent on the relative uniformity or variability of the hosted/protected content and the access-denied URLs. The following sections have more information.

• Using a Single Policy Agent

• Using Multiple Policy Agents

A reverse proxy server or a load balancer with a reverse proxy feature is usually installed between the outer firewall and the inner firewall - in the DMZ between the internet and the secure intranet. See Chapter 8, Configuring the Protected Resource Host Machines, in Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0, Chapter 9, Setting Up Load Balancers for the Policy Agents, in Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0 and Sun OpenSSO Enterprise Policy Agent 3.0 Guide for Sun Java System Web Proxy Server 4.0.x for installation and configuration information.

Using a Single Policy Agent

When there is a uniformity in the configuration of the content servers in the back end (including access denied URLs, application logout URLs, profile, session and response attributes, and the web container type), a single policy agent for the reverse proxy server would be the efficient way of protecting the content. The following diagram illustrates this.

Regardless of the number of content servers being fronted by the reverse proxy, only one agent is installed on the reverse proxy machine. The footprint of this configuration is less cost (fewer agents to maintain) and less memory (a single agent requires less memory to cache). With one agent no communication will occur between the content servers and the OpenSSO server. The policy agent will have back channel communications with the OpenSSO load balancer to update cache entries, perform session validation, and make policy requests but, since the agent is installed on the reverse proxy server and not on the content servers, only the reverse proxy server would communicate with the OpenSSO load balancer. This effectively reduces the number of communication channels which would result in fewer firewall rules, tighter control over server-to-server communications, and a higher level of security. On the other hand, one agent does not allow identification of content servers which may impact application usage reports. One agent also uses the same session identifier introducing the risk of cookie hijacking.

Using Multiple Policy Agents

When a number of content servers use different types of web containers or each content server has different access denied URLs, agent profiles, session and response attributes, and application logout URLs, the only choice is to install multiple policy agents. Each agent will have its own customized agent profile. The following diagram illustrates this.

Unlike in the case of the single reverse proxy server policy agent where the same session identifier is used to access many applications protected by the agent, multiple policy agents do not use the same session identifier (when the agents are configured in cookie hijacking prevention mode). With multiple agents, it is now easy to customize agent properties per content server; for example, customize profile attributes to be fetched, session attributes to be fetched, response attributes to be added to the header, URL of the access denied page, customized application error pages, and application logout URLs. By customizing each application's logout URL, it is possible to perform cleanup tasks — such as destroying the user's session or resetting cookies — per application. (Customizing certain agent properties with only one policy agent might create a security risk.)