This is a discussion on Agents Belong with OpenSSO and Reverse Proxy - Solaris Rss ; If your OpenSSO deployment architecture includes a reverse proxy server , 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 ...
If your OpenSSO deployment architecture includes a reverse proxy server, 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.
NOTE: 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 demilitarized zone (DMZ) between the internet and the secure intranet.
Using a Single 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.
Using Multiple 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.
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 (destroying the user's session or resetting cookies) per application.
See the following links for more information.
- Installing Policy Agent 2.2 for Sun Java System Web Proxy Server 4.0
- For configuring the protected resource host machines and setting up load balancers for the policy agents, see Chapter 8 Configuring the Protected Resource Host Machines and Chapter 9 Setting Up Load Balancers for the Policy Agents of Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0
Piggybacking on the music videos from Accessing OpenSSO from Outside a Secure Intranet (Put a Lock On It), here's the Taylor Swift video that won the VMA - against Kanye's better wishes.