Ajax in the network: the security and topology problems of aggregating content from multiple sites in an AJAX architecture

When trying to introduce asynchronous Javascript™and XML (AJAX) programming technology into a network environment, there are often some difficulties encountered.

Brief introduction

An exciting feature of Ajax architecture is the ability to aggregate content from multiple data sources and create an entirely new site or WEB application. For example, you can create a WEB application that combines information from a variety of meteorological services to provide weather information for several ski resorts. These weather information can be obtained from several web sites, and your application brings the data to a Web page together. Such applications are often referred to as mashups. Without delving into it, you can fully appreciate the possibilities of creating such Web applications with the help of Google or Yahoo.

Creating a network topology to support content aggregation from multiple sites requires many technical challenges. These technical challenges include cross-domain limits for browsers, possible expiration of user sessions, persistent connection timeouts, and possible authentication and authorization issues. This article looks at these technical challenges related to Ajax and explores how to synthesize the use of IBM WebSphere application Server Feature Pack for Web 2.0 and IBM Tivoli Access Manager Web SEAL to address these technical challenges.

Ajax topology

Figure 1 shows a typical Ajax-style architecture. On the left side is a client, such as a Web browser. In this example, the browser supports the JavaScript programming language, which is used to process the Document Object Model (DOM) of the browsed page. These pages may contain JavaScript widgets that perform a GUI function. For example, you might create a widget that pulls data from the server and displays the content on the browser. This widget is responsible for the creation and manipulation of the DOM, and the browser uses the DOM to display the graphics content.

Figure 1. Ajax schemas that use proxies

SOAP, ATOM, XML, JSON

When a client connects to a server for data exchange, there is always a convention format for how data is interpreted. SOAP, ATOM, XML, and JSON are common formats that the server and client exchange for information when they connect. Each of these technologies has advantages and disadvantages. Exactly which technology you use depends on the specific needs of the WEB application you are developing. The Web 2.0 feature package provides support for these protocols on both the server side and the client, helping to simplify WEB development.

The center of Figure 1 is a forward proxy. If you want to aggregate content from more than one WEB service or need to enforce a security mechanism on those clients connected to the network, the proxy is more important for the Ajax architecture. For example, Ajax relies heavily on xmlhttprequests to send a network connection in the background to retrieve data. By design, modern browsers do not allow xmlhttprequests to reach those fields beyond the recorded origin. For example, if you create a JavaScript GUI widget that originates from http://www.mysite.com, but then sends a xmlhttprequest to the http://www.mydata.com/data to pull out the data, The request will be blocked by the browser. Instead, the client connects to the broker acting as the broker and arranges the client's requests to other domains. From the client's perspective, the request looks like it originated from the same domain as the original document. In addition to working with the browser's own security model, the agent can provide an additional layer of authentication and authorization to act as a control point for accessing documents or services on the network.

The right side of Figure 1 is the various services or document endpoints that the browser-based client may be trying to access. In the Ajax architecture, these service endpoints may access a database, Enterprise service bus, or other back-end services to pull out information that is returned in a format that is available to the client point. Typical examples include SOAP, ATOM, XML, or JSON.