Chapter 19 Accessing OpenSSO from Outside a Secure Intranet

One of the major decisions in deployment planning is how to set up access to OpenSSO Enterprise from outside a secure intranet. This chapter discusses two options: using a reverse proxy or using the Distributed Authentication User Interface (DAUI). Both options allow Authentication Service pages to be served to users over a firewall (for example) thus preventing direct access to OpenSSO Enterprise by unauthorized users.

This chapter includes the following topics:

• Using OpenSSO Distributed Authentication User Interface

• Using a Reverse Proxy

• Using Policy Agents with Reverse Proxy

Using OpenSSO Distributed Authentication User Interface

OpenSSO Enterprise provides an authentication interface that can be deployed between the outer internet firewall and the inner intranet firewall - in the DMZ - to enable secure authentication communications to the OpenSSO Enterprise server. Deploying the Distributed Authentication User Interface (DAUI) to one or more web containers within a non-secure layer eliminates the exposure of service URLs to the end user, and prevents direct access to the OpenSSO configuration and user data stores by unauthorized users. The following diagram illustrates the deployment.

The DAUI is best used when various authentication modules/chains are configured and thus customized content needs to be presented to different user clients and/or agents. The DAUI is a flexible option for customizing content in the DMZ. The OpenSSO server is completely hidden from the external clients because all communication is mediated by the OpenSSO Client SDK calls. Benefits of the DAUI include:

• Eliminate direct client/server traffic The DAUI receives all client authentication requests and, in turn, sends them to the back-end OpenSSO server, even eliminating encrypted traffic between the external clients and the OpenSSO Enterprise server.

• Authentication Service support All authentication modules are supported via the DAUI.

• Dynamic customization of pages Each incoming request can be routed to different DAUI pages, dependent on the authentication chain or module being used. These DAUI pages are customized in the DMZ so access to the back-end OpenSSO Enterprise server is not necessary.

See Chapter 7, Installing and Configuring the Distributed Authentication User Interface, in Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0 for more information.

The DAUI WAR cannot be used for federation communications between the client SDK in the DMZ and the back-end OpenSSO server. All federation API calls (including SAMLv2, Liberty ID-FF, and Web Services Security) must communicate directly with OpenSSO.

Using a Reverse Proxy

As an application proxy does, a reverse proxy acts as a gateway between a protected HTTP server and requests to the HTTP server that originate from outside the secure intranet. A reverse proxy is installed between the outer internet firewall and the inner intranet firewall - referred to as the demilitarized zone (DMZ) - to prevent direct access to the OpenSSO configuration and user data stores by unauthorized users. A reverse proxy can be implemented as Sun Web Proxy Server 4.0.9 or as Sun Web Server 7.0 Update 3 or later with the reverse proxy plugin. It requires an SSL-enabled port for communication between the external client and the back-end OpenSSO Enterprise server. The following diagram illustrates the deployment.

A reverse proxy is best used when the content to be presented is uniform. This is generally the case when there is only one authentication module or authentication chain configured thus only one user interface page is served and that page is hardly changed. Taking advantage of the caching and compression capabilities of the reverse proxy, the page can be served very quickly. Also using a reverse proxy can be an acceptable and efficient way of distributing the load among web servers. Benefits of reverse proxy servers include:

• Caching for improved performance When static content is cached, the reverse proxy would not forward a request for the content to OpenSSO Enterprise; it would respond to the request by serving the content itself. This could lower the request load, thereby improving performance of the server and potentially lower response times to the client.

• Additional layer of security By introducing an additional layer of security, access to the OpenSSO Enterprise server is further limited. This additional layer offers the opportunity to monitor traffic, to perform a wider set of checks (for example, malformed URL strings can be stopped at the proxy), and to react to attacks sooner.

• Persistent load balancing Configure the name of a sticky cookie or sticky URI parameter (in the reverse proxy configuration) to allow subsequent requests to stick to the same OpenSSO server that responded to the first request. Stickiness affects OpenSSO Enterprise performance positively.

• Compression for speedy load times Outgoing traffic can be transparently compressed thus lowering total bandwidth requirements. A reverse proxy supports various compression levels and fragment sizes, allowing the administrator to select a level of compromise between speed and compression.

• Spoon feeding dynamic content Dynamically generated content can be returned from the back end server a little at a time.

As most reverse proxies have limited load balancing capabilities, thought should be put into whether you would use a reverse proxy or a reverse proxy capable load balancer. For example, reverse proxy software would require additional hardware whereas load balancers are fairly common.

See Sun Java System Web Proxy Server 4.0.12 Installation and Migration Guide and chapters 3 and 4 in Using the Java System Web Server as a Reverse Proxy for Improved Security for more information.

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.)