Agents Belong with OpenSSO and Reverse Proxy

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.

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.


Hi Michael

I configured my OpenSSO using reverse proxy.
I’m using the Apache http server as a proxy server with web agent 3.0
The Http open ports are 80 and 443.
My Agent is listing to port 80 and working fine.
I want that my agent will listen to the https port (443) as well.
I couldn’t figure out how to do it.
I can’t add another agent to the same http server.
Is it possible to configure this? What is the right way to do it?


Posted by Yaakov on September 22, 2009 at 12:29 AM PDT #

Hi Yaakov. I'm not an agent specialist but maybe this section of the Deployment Example will help:

You might also try the agent docs or, if all else fails, the OpenSSO users alias.

Posted by Michael Teger on September 22, 2009 at 01:12 AM PDT #

Hi Michael,

I'm actually implementing a similar architecture with a single agent on a proxy that fronts multiple content servers. I've noticed that when I access the proxies through the load balancer, the Policy Agent can't seem to identify the port of the original request and appends an 80 by default and sends it along as the goto URL parameter. This is fine for applications that need the clear port, but not good when a load balancer VIP needs to be on https/443 (obviously 80 will not work there).

Any ideas why the agent can't find the port and is defaulting to 80?

If i access the server directly on its HTTPS port, it recognizes the port. Is there some load balancing configuration I need to do?

Posted by AJ on October 15, 2009 at 02:05 PM PDT #

Hi AJ. I did not actually implement this deployment; just found the info. I suggest you send your question to and see if anyone else has an answer.

Posted by Michael Teger on October 19, 2009 at 10:08 PM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016