Integrating Web applications with the DataPower Web application firewall service


You can use IBM® WebSphere® DataPower® SOA Appliances to enforce security within your enterprise by deploying them on your company intranet or the "DMZ." The Web application firewall service in DataPower can execute a security policy on messages that arrive in the DMZ before sending them to a back-end Web application. These tasks may also be performed on J2EE application servers such as WebSphere Application Server, but configuration using the DataPower management interface is much easier and does not require custom code. In addition, DataPower Appliances can provide a single enforcement point for many applications within your enterprise.

This article shows you how to use the DataPower Web application firewall (WAF) service to integrate with Web-based applications. You will learn how to configure the WAF service to virtualize a back-end Web application, handle rate limit requests, and enforce an AAA policy. You should have some familiarity with configuring services on DataPower Appliances.

The WAF service can listen for requests on multiple TCP ports to virtualize or proxy back-end Web applications. The WAF service can also require Web clients to send requests over Secure Sockets Layer (SSL). In situations when you need to limit the number of requests being sent to the back-end Web service, you can create a rate limiting policy to control the number of requests. You can also require clients to provide credentials when trying to access the Web application, which can be enforced using a DataPower AAA policy.

Scenario description

In this scenario, you use a Web browser as an external client to connect to the Web application firewall service in DataPower. Once you have been authenticated, your request is forwarded to the back-end Web application. The Web application firewall service uses an AAA policy to validate users. In a production environment you would also need to secure the connection from the Web application firewall service to the back-end Web application, using either a security token or SSL. That step has been omitted from this article.

Figure 1
Figure 1
Figure 1

Host virtualization

DataPower Appliances are typically deployed in the DMZ, which lets them perform pre-processing on incoming messages before they enter a company intranet. Web clients should not know the back-end endpoint of your Web application, first, because if the back-end endpoint changes, your Web clients need to be notified of those changes, and second, because malicious users can send multiple requests to try to overwhelm the back-end Web application. To hide the Web application end-point address from Web clients, you can define multiple TCP ports on which the WAF service listens for requests. This step is required when you are creating the WAF service.

Defining the WAF service front- and back-end information

You first need to create a WAF service on the DataPower Appliance. Start by defining the front- and back-end information for the service:

  1. Log in to the DataPower Web GUI using your username, password, and domain.
  2. In the DataPower Control Panel, click Web Application Firewall:
    Figure 2
    Figure 2
  3. On the Configure Web Application Firewall page, click Add wizard. The wizard then asks you a series of questions to generate a WAF service.
  4. Enter the name for your WAF as AddressWAF.
  5. For Remote host address and Remote IP port, enter your back-end server address port number and click Next. The remote host address and IP port is the destination to which requests are forwarded after they are processed by the Web application firewall.
  6. For the Front-end (client-facing) information, leave the IP as (listens for requests on all Ethernet interfaces), enter the port number that the WAF service will use to listen for requests, and click Add:
    Figure 3.
  7. The WAF service can listen for requests on multiple TCP ports. You can repeat this step for each port number that the WAF service will use to listen for requests. You can also specify that the incoming connection for the port number should use SSL. If you check SSL then you must create or use an existing SSL Server Crypto Profile, which defines the keys and certificates that will be used in an SSL session.
  8. Click Next.

Create an AAA policy

In the next step of the wizard, you create an AAA policy that extracts the credentials from an HTTP message and performs authentication using an AAA file.


  1. Create a new AAA policy by clicking the + button.
  2. Create a new access control policy named AddressAdmin to identify the user from the HTTP authentication header.
  3. On the "Configure an access control policy" page, name the new AAA policy AddressAdmin. Click Create to apply the changes.
  4. The "Define how to extract a user’s identify from an incoming request" page determines how the access control policy identifies the client from the incoming request message. Select HTTP authentication header and click Next:
    Figure 4.
  5. The "Define how to authenticate the user" page determines how the policy validates the user identity stated within the incoming request message. Select Use DataPower AAA info file as the method.

    In a production environment, an authorized users list usually resides in a corporate directory server, such as a Lightweight Directory Access Protocol (LDAP) server. In this example, the list of authorized users resides in an XML file named AAAInfo.xml. Since the file is included with every DataPower Appliance, use it only for testing.

  6. In the URL section at the bottom of the page, select the actual AAA info file. Switch to the store: file location and select AAAInfo.xml:
    Figure 5.
  7. Leave the credential mapping method as none and then click Next.


Configure the authorization step in the access control policy to allow any authenticated user.

  1. The "Define how to extract the resources" page specifies how the access control policy determines which resource the client has requested. In this scenario, the resource is the URL sent by client:
    Figure 6.
  2. Leave the resource mapping method as none and then click Next.
  3. The "Define how to authorize a request" page determines the access rules based on the resource and user. Select Allow any authenticated client and click Next.


The last page of the AAA policy wizard lets you configure monitoring, logging, and post-processing options.

Examine the monitors for the access control policy. The Authorized Counter and the Rejected Counter keep track of how many requests were allowed or denied access, respectively. The rejected counter has an additional feature to block further requests if a threshold is reached.

The Logging section keeps track of the request and response message details for any authorized or rejected access attempts. The amount of message detail logged depends on the log level you configure.

The post-processing section describes actions that you can apply to the message after the authentication, authorization, and auditing steps:

  1. Save the settings for the AddressAdmin access control policy.
  2. Click Commit to save the AddressAdmin access control policy, and then click Done.
  3. The next page lets you create a Name Value profile to validate name-value pairs in the request. Click Next.
  4. The next page lets you configure how to handle query strings and cookies. Click Next.
  5. Click Commit to create the WAF service.

Rate limiting

High-volume Web sites may need to limit requests during certain periods. For example, a concert ticket Web site may experience a spike in traffic when concert tickets first go on sale. The WAF service lets you restrict the number of request messages within a given time interval. Requests over the specified number can be rejected, shaped, or logged. You can also limit the number of users connected and number of connections per user.

In the WAF service, create a Rate Limiting object to limit the number of request messages:

  1. Open the application security policy object to view the generated object.

    In the Web page that opens, verify that you see three tabs: Request Maps, Response Maps, and Error map. Request Maps contains a list of security profiles that execute for a request message when matched by a matching rule. Response Map is similar, except that it applies for the response message.

  2. Click the Request maps tab and open the AddressWAF_request rule.
  3. Click the Profile tab.
  4. Click the + sign to create a new Rate Limiting object.
  5. Enter the name AddressRL. You can change the rate from 500 to a different value based on the requirements of your application. Enter a small value such as 3 for testing:
    Figure 7.
  6. Click Apply.
  7. Save all open windows and click Apply in the WAF service config page.

Test the WAF

Use a Web browser to test the WAF service:

  1. Open a Web browser and enter the Web application firewall URL: http://<DP_address>:<waf_address_port>/EastAddress/addressSearch.jsp.
  2. When challenged, enter fred for username and flintstone for password. Click OK. Make sure that you have logged in successfully and can see your initial page.
  3. Try sending multiple requests simultaneously to trigger the rate policy.


The DataPower Web application firewall service can simplify management of your back-end Web applications. You can use it to virtualize the endpoint address, handle rate limit requests, and enforce access control. You can configure these items using the Web application firewall service without writing any custom code.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Integrating Web applications with the DataPower Web application firewall service