DocTeger

OpenSSO Technical Information

And a Spoonful of Music

To Make the Medicine Go Down

Accessing OpenSSO from Outside a Secure Intranet (Put a Lock On It)

One of the major decisions in deployment planning is how to set up access to OpenSSO from outside a secure intranet. This information 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 by unauthorized users.

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 - in what is 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 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; 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 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 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 but at a time.
• Encryption and SSL acceleration.

See the following links for more information.

• Installing Sun Java System Web Proxy Server
• Using the Java System Web Server as a Reverse Proxy for Improved Security: See chapters 3 and 4
• Configure reverse proxy in few seconds blog entry
• Agents Belong with OpenSSO and Reverse Proxy blog entry

Using OpenSSO Distributed Authentication User Interface

OpenSSO 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 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 all 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 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 server is not necessary.

See Installing and Configuring the Distributed Authentication User Interface (a portion of the Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0 document) for more information.

Note: 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.

With all the hulabaloo about Kanye West and his interruption of Taylor Swift's acceptance of her MTV video award in Beyonce's name, let's take a look at Single Ladies (Put A Ring On It) (the video Kanye thought should win)...

...and the Bob Fosse choreographed Mexican Breakfast (with Gwen Verdon) that started the whole thing, um, 40 years ago.

Posted at 12:00AM Sep 14, 2009 by Michael Teger in Sun  |  Comments[0]