Ajax in a network

Security and topology challenges of aggregating content from multiple sites in an Ajax architecture

Using WebSphere Application Server Feature Pack for Web 2.0 and Tivoli Access Manager WebSEAL


An exciting feature of an Ajax architecture is the ability to aggregate content from multiple data sources to create an entirely new and innovative site or Web application. As an example, you might create a Web application that combines information on ski resorts with information about weather that is available from various weather services. The information is available across several Web sites, but your application brings this data together on one Web page. These types of applications are often referred to as mashups and you don’t have to look much further than Google or Yahoo to see the innovative possibilities in creating Web applications of this type.

Creating the network topology to support aggregation of content from multiple sites has a number of technical challenges. The challenges include accounting for cross domain restrictions of the browser, possible user session expiration, persistent connections timeouts, and possible authentication and authorization issues. This article looks at the technical challenges associated with Ajax and explores how the IBM WebSphere Application Server Feature Pack for Web 2.0 combined with IBM Tivoli Access Manager WebSEAL can be used to solve these technical challenges.

Ajax topology

Figure 1 shows a typical Ajax style architecture. On the left is a client, such as a Web browser. In the example, the browser supports the JavaScript programming language, which is used to manipulate the Document Object Model (DOM) of the page being viewed. The pages might contain JavaScript widgets, which perform a GUI function. As an example, you might create a widget that pulls data from the server and displays the contents on the browser. The widget handles the creation and manipulation of the DOM which the browser uses to display graphical content.

Figure 1. Ajax architecture using a proxy
Figure 1. Ajax architecture using a proxy
Figure 1. Ajax architecture using a proxy

In the center of Figure 1 is a forwarding proxy. A proxy is important to an Ajax architecture if you plan to aggregate content from multiple Web services or if you need to enforce a security mechanism on clients connecting to the network. As an example, Ajax relies heavily on XMLHTTPRequests to issue behind the scenes network connections for retrieving data. By design, modern browsers do not permit XMLHTTPRequests to domains that originate from outside of where the documented originated. As an example, if the JavaScript GUI widget you created originated from, but then issues an XMLHTTPRequest to to pull data, the request will be blocked by the browser. Instead, the client connects to the proxy which acts as an intermediary, brokering the client’s requests to other domains. From the client’s perspective, the request appears to be originating from the same domain as the original document. In addition to working with the browser’s own security model, the proxy might provide an additional layer of authentication and authorization in order to act as a control point for access to documents or services on the network.

On the right of Figure 1 are various service or document endpoints that browser-based clients might be trying to access. In an Ajax architecture, these service endpoints might access a database, Enterprise Service Bus, or other back-end service to pull information. The information returned is in a format that is consumable to the client endpoint. Typical examples include SOAP, ATOM, XML, or JSON.

Pulling it all together

The IBM WebSphere Application Server Feature Pack for Web 2.0 is an optional add-on for WebSphere Application Server Versions 6.0, 6.1 and 7.0. In addition, it supports IBM WebSphere Application Server Community Edition V2.x. The feature pack contains client-side and server-side technology that can be used to create Ajax style architectures. The technology is provided in the form of libraries that can be included with your Web application. As a developer, you select the library packages that are appropriate to the Ajax Web application you are working to create. The lists below summarize the features available in the Web 2.0 feature pack.


  • Dojo 1.1 Toolkit is a JavaScript toolkit that simplifies the creation of Ajax applications using JavaScript.
  • IBM Extensions to Dojo
    • JavaScript library for handling SOAP or Atom feed content.
    • Gauge GUI widgets
    • OpenSearch library


  • A Java-based JSON library which is used to create JSON data that is easily consumed by JavaScript-based clients.
  • Abdera-based feed libraries that can be used to create ATOM feeds.
  • A servlet-based Ajax proxy that can be embedded in your application.
  • Ajax messaging used to create Comet-style architectures.

IBM Tivoli Access Manager WebSEAL is a reverse Web proxy that receives HTTP/HTTPS requests from a browser-based client and delivers content from its own Web server or accesses back-end Web application servers such as WebSphere Application Server. Requests passing through WebSEAL are evaluated to determine whether the user is authorized to access a requested resource. WebSEAL supports these features:

  • Pluggable architecture that supports a variety of authentication mechanisms.
  • Accepts both HTTP and HTTPS requests.
  • Protects back-end server resources by providing fine-grained access control for local and back-end server Web space.
  • Performs as a reverse Web proxy.
  • Provides single sign-on capabilities.
  • Has many positive integrations stories with third party software products.

Figure 2 shows a revised topology diagram and shows how the Web 2.0 feature pack and WebSEAL can be used together to deliver a Web-based Ajax solution. WebSEAL forms the basis of the network topology by providing proxy and security services, while the Web 2.0 feature pack provides the application libraries to create Ajax styled Web applications.

Figure 2. Updated topology using WebSEAL as the proxy
Figure 2. Updated topology using WebSEAL as the proxy
Figure 2. Updated topology using WebSEAL as the proxy

On the client-side, the Web 2.0 feature pack provides the Dojo 1.1 JavaScript toolkit. The Dojo Toolkit is an open source solution that can be used to create Ajax style architectures. The Dojo Toolkit is grouped around three components:

  • Core consists of a compact JavaScript library that provides the framework upon which other components of Dojo are built upon. Framework support is provided for events, packaging, CSS-based querying, animations, JSON handling, and more. Sitting on top of Core is Dijit.
  • Dijit is a set of customizable template driven widgets that support localization and accessibility. Dijit contains a very rich set of widgets that can be used out-of-the-box or customized to your requirements. In addition to Dijit is Dojox.
  • Dojox contains innovative components such as charting, offline support, grids, and more.

Additionally, IBM provides JavaScript libraries with the Web 2.0 feature pack for handling SOAP and ATOM formats, as well as GUI-based widgets for creating analog style gauges, such as for a dashboard.

In the center of the diagram in Figure 2 is Tivoli's WebSEAL product, which serves the role of a proxy and provides a security mechanism to control access to documents and Web objects in the network. The connection between the WebSEAL server and a back-end Web application server is referred to as a WebSEAL junction. A WebSEAL junction can be considered a logical mount point in the WebSEAL Web space and is illustrated in Figure 3. A junction creates a logical representation of the Web documents and enables WebSEAL to provide security on behalf of the back-end server to which WebSEAL is connected. Since WebSEAL junctions create a logical mapping between the Web space of a back-end application server, junctions can be used to create a transparent mapping for the user or Web application. As an example, if the Web application you created originates from, but accesses customer data from, you can create a WebSEAL junction that maps access to WebSEAL seamlessly maps the request to the and returns the data back to the client.

Figure 3. Topology with Tivoli WebSEAL junction
Figure 3. Topology with Tivoli WebSEAL                     junction
Figure 3. Topology with Tivoli WebSEAL junction

If the server requires fine-grain security to a directory, then a junction is created on WebSEAL which identifies the Web object or document that requires additional authentication and authorization. Tivoli Access Manager provides the security framework which WebSEAL ties into.

WebSEAL will receive a URL request from the client and, based on the junction configuration, will issue a request to the server. From the server’s perspective, WebSEAL appears as just another client requesting information. Depending on the data returned, the server will format the data into the appropriate protocol, such as JSON, ATOM, SOAP, or XML. Depending on the protocol being returned, the Web 2.0 feature pack provides application server-side technology that can make returning the data content easier:

  • JSON4J is a Java library that can be used within your application to create JSON formatted data streams. As an example, you might need to return columns in a table from an SQL database. JSON4J can be used to format the data into a JSON data stream, which is then returned back to the client.
  • Abdera 0.40 is provided with the Web 2.0 feature pack and can be used to create ATOM style publishing feeds from the server. The feeds can represent news information, or any other publishing content.
  • RPCAdapter enables you to invoke Java methods using JavaScript. Specifically, you create a JSON data stream on the client that contains the methods to invoke and the parameters. The data is sent to RPCAdapter, which looks at the JSON request and calls the specified method. The response from the method could be a Java Bean, which is serialized into either an XML or JSON data stream and returned back to the client. The RPCAdapter enables easier mapping of legacy Java Beans to formats that are consumable to an Ajax-based client.

Scenarios depicting challenges in deploying an Ajax architecture

Depending on the application and complexity, a number of questions might need to be answered before deploying an Ajax style architecture into a network. Here are some examples:

User session expiration

Using the architecture above, consider the scenario where you have created a Dojo JavaScript widget that requests data to a server to display in a table. The widget uses Dojo's xhrGet function to issue an XMLHTTPRequest to the server. The proxy forwards the request to the server and the server responds with a JSON data stream, which the Dojo widget easily parses to display data. What happens when the WebSEAL proxy session expires because of a timeout or the maximum number of sessions is exceeded?

From the widget’s perspective, the code issues a request and expects the return format as JSON. Instead, the widget receives an HTML response, which is a Web form login page. The Web form login page requests a user ID and password. Normally, a Web login is not a problem, but since the underlining request to the server is occurring under the covers, there is no obvious user action to the login. Figure 4 illustrates the problem.

Figure 4. User Session expiration
Figure 4. User Session expiration
Figure 4. User Session expiration

From WebSEAL's perspective when a user's session expires, it caches the last request issued and returns the Tivoli Access Manager login form. When the login form has been submitted, WebSEAL and the user re-authenticated WebSEAL resubmit the request. In a complex Ajax application, this generally causes a loss of context. By intercepting this behaviour, you can remember this context and work towards restoring it to provide the optimal user experience.

Possible solution

A solution here is to recognize when you don't receive the correct data and respond accordingly. In the case of JSON data, the key is to use dojo.fromJSON(data) and parse the JSON response. The parse will fail if you receive HTML from a form login or an HTML error page from the server. If there is a problem, catch the exception and go from there. HTTP error condition codes can be caught by the error function. The ioArgs parameter provides additional attributes that you can use to narrow down the problem.

Listing 1. Sample solution
        var timer = null;
        // Function that retrieves a JSON object and puts the information
        // into the div with an id of 'json-content'. Notice how we're defining
        // 'handleAs' to be of type 'text'. We we handle the parsing of the JSON
        // data so that we can trap the exception if it occurs.
        function getJson () {
            var d = dojo.xhrGet ({
                                  url:      '/webseal/login',
                                  handleAs: 'text', 
                                  load:     loadIntoNode,
                                  error:    errorCondition

          function loadIntoNode(data, ioArgs){
                console.log("Read JSON Data ... do something",data);
		// read the JSON data that was returned by the service 
                var jsonData = dojo.fromJson(data);

                //do something with the JSON data that you read
		//dojo.byId("json-content").innerHTML = data;

                // respond with an error reading JSON.  As an example, if an HTML form
                // login is returned, then dojo.fromJson will throw an Exception. 
                // Catch the exception and dispaly a login box. At this point, we
                // are assuming the error condition is because Dojo can't parse the
                // JSON stream. You can fine tune the error condition by looking at
                // the e.message value
		        console.log("error reading json data ",e.message);
                // Do something on the error condition, display a login widget, or 
                // look at the ioArgs to further narrow the problem down.

          function errorCondition(error,ioArgs){

            // retrieve an error message for the HTTP response code.  As an 
            // example, if we get a 500 (Server Error) then take an action.

            switch(ioArgs.xhr.status) {
            case 404: //page not found error
            case 500: // server side error
            case 407: // proxy authentication
            default: // default action

            console.log("HTTP Error code:",ioArgs.xhr.status);
            console.log("Error Condition:",error.responseText);
	        console.log("Error Message:  ",error.message);
	        //dojo.byId("json-content").innerHTML = ioArgs.xhr.status;

Persistent connection

Maintaining a persistent connection between a client and a Web server is becoming a popular technique in Ajax environments. As an example, the Web 2.0 feature pack supports the Comet programming model. Comet is a Web application model where a long-held HTTP connection enables the server to push data to the browser without the browser requesting the data. Since the connection to the server is always open, the server can easily push new data to the client. When the timeout connection expires, the JavaScript library reopens the connection to the server and keeps it open until it times out. The process repeats itself with the JavaScript library opening the connection again.

A typical example would be a stock-quote application where changing price information is pushed to the browser without user interaction. From the user’s perspective, they see the change occur instantly. The Comet programming model contrasts with a polling model where the client opens a connection, requests an update, and then closes the connection again. The effect of the Comet programming model is that persistent connections are held open to the service endpoints to which the client is connecting. Figure 5 illustrates the scenario.

Figure 5. Comet programming model
Figure 5. Comet programming model
Figure 5. Comet programming model

The implication of this for WebSEAL is that users with active sessions will be holding open at least one long-running connection to the server, in addition to the shorter connections that are generated from other user-initiated requests. This will consume WebSEAL worker threads, and the value of the [server] worker-threads parameter might need to be tuned in the WebSEAL configuration file. In extreme cases where a high number of active user sessions are anticipated, it might be necessary to add WebSEAL instances.

Possible solution

Determine if there is an issue with the current setting of the [server] worker-threads parameter, as configured in the WebSEAL configuration file. The simplest method to determine if there is an issue is to use WebSEAL statistics. Specifically, monitor the output of the pdweb.threads component. (Listing 2)

Listing 2. Output from a statistics get command for pdweb.threads component
#pdadmin> server task default-webseald-instance stats get pdweb.threads
active : 0 total : 50

If the reported value of active is continually reaching the value of total, then you should make more worker threads available. For more details on configuring WebSEAL worker threads, refer to the WebSEAL Performance Tuning Guide. For more details on gathering WebSEAL statistics, refer to the Tivoli Access Manager for e-business Problem Determination Guide and the Tivoli Access Manager for e-business Auditing Guide.

Authentication and authorization

Depending on the Web application being developed, a requirement might exist to control access to Web documents or the types of servers to which the Web application is allowed to connect. While it's beyond the scope of this article to explain Tivoli Access Manager authentication and authorization architecture (which is used by WebSEAL), a short description will help you understand the issues when creating Ajax style architectures that involve WebSEAL.

Tivoli Access Manager contains a security policy which defines access to a domain. The domain is governed by two security structures: The user registry, such as LDAP, Lotus Domino, or Microsoft Active Directory, and a master authorization policy database. The user registry contains the users and groups that are permitted to participate in the domain and completes the authentication. The authorization policy database contains a representation of all resources in the domain. The security administrator can dictate the level of security by applying rules known as protected object policies (POP) and access control lists (ACL). A protected object could be a Web resource, such as a page or a URL to a service end point to which your browser client is attempting to connect.

Depending on how WebSEAL is configured, clients can connect to a secure domain as either authenticated or unauthenticated. Only users with an entry in the user registry can become authenticated users.

The WebSEAL proxy receives a request from your browser’s client from your Dojo widget. Accessing protected objects from an unauthenticated client or an account with lower privileges than required will return a login prompt or "HTTP 401" error, respectively. A user agent, such as the browser, understands how to handle these scenarios; however, a typical client who is using Ajax as the requesting mechanism won't understand.

Link re-writing and the same origin policy

For a standard WebSEAL junction, JavaScript filtering is only performed if it is configured to do so. That is, the junction is created using the -j option.

The majority of Web developers will write their JavaScript code to contain URL information. This URL information will not be re-written by WebSEAL, and as such can cause a variety of issues, mainly around dead links. However, a specific issue also exists for requests made with the XMLHttpRequest object, due to the same origin policy that is enforced by the JavaScript language.

The following example demonstrates how a Web developer would typically write their Ajax content. By separating JavaScript operations from HTML content, you enable better reuse of resources. However, if there is URL content defined in the JavaScript, then you will need to enable script filtering in WebSEAL. Consider the scenario illustrated in Listings 3 and 4.

Listing 3. widget.js
        function getXML () {
            var url_1 = "";
            var url_2 = "http://" + server + ":" + port + "/sales.xml";
            var url_3 = "/sales.xml";
            var url_4 = "sales.xml";
            var d = dojo.xhrGet ({
                                  url:      url_1,
                                  handleAs: 'text', 
                                  load:     loadIntoNode,
                                  error:    errorCondition
        function loadIntoNode(data, ioArgs){
            // process XML file
Listing 4. widget.html
<body class="tundra">

<button id="1469" dojoType="dijit.form.Button" onClick="getXML();")'>
XML Data Button


In the example above, these problems occur:

  • The URLs will not be rewritten unless script filtering has been configured correctly.
  • If the link is not re-written, an exception will be raised by the browser, as it would be seen as violating the same origin policy.
  • If script filtering was enabled, the variable url_1 defined in example.js would be re-written by WebSEAL.
  • Even with script filtering configured correctly, WebSEAL is not able to interpret the level of dynamic link construction that is used in url_2.
  • Although WebSEAL has the capability to filter JavaScript, it is often difficult to differentiate between a variable that is intended to be a string literal and a relative or server-relative URL. Absolute URLs will be re-written correctly, and as relative URLs do not need to be altered, the only type of URLs that will cause problems here are server-relative URLs. This is because WebSEAL must add the junction name to the path of server-relative URLs that refer to resources located on junctioned servers. If it is unable to determine if a variable declared like url_3 is a server-relative URL, then all requests that are issued in this way will result in dead links.

Possible solution

WebSEAL is intelligent enough to filter JavaScript, but you need to tell it to do so. If you turn on JavaScript filtering only, you won't get the desired effect. A standard configuration for WebSEAL with JavaScript filtering enabled will only look for URLs in content similar to the entries in the table below.

Unfiltered contentFiltered content
<a href="javascript:doRequest('')">click here</a><a href="javascript:doRequest('')">click here</a>
<script type="text/javascript" src="//"></script><<script type="text/javascript" src="//"></script>

To get the content defined within an external JavaScript inspected, you need to use a configuration like that shown in Listing 5.

Listing 4. Changes required in webseald.conf
type = text/html
type = text/xml
type = text/javascript

script-filter = yes

Another possible approach is to utilize virtual host junctions, if this suits your existing infrastructure. By doing this, you are effectively eliminating the need to filter URLs within HTML content. You will have a lot fewer issues when it is time to rewrite URLs within your client-side scripts. However, virtual host junctions are not suitable for all deployments of WebSEAL within an enterprise, so it is really a matter of choosing what is best for your environment.


This article demonstrated how IBM Tivoli Access Manager WebSEAL can be used in conjunction with the IBM WebSphere Application Server Feature Pack for Web 2.0. WebSEAL can be used to provide a secure network proxy environment while the Web 2.0 feature pack provides the server and client application technologies to create Ajax style architectures. By providing sample scenarios, the article explored a number of issues that can arise, along with potential solutions.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=WebSphere, Web development, Tivoli (service management), Tivoli, Security
ArticleTitle=Ajax in a network: Security and topology challenges of aggregating content from multiple sites in an Ajax architecture