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.
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.
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:
- Log in to the DataPower Web GUI using your username, password, and domain.
- In the DataPower Control Panel, click Web Application Firewall:
- On the Configure Web Application Firewall page, click Add wizard. The wizard then asks you a series of questions to generate a WAF service.
- Enter the name for your WAF as
- 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.
- For the Front-end (client-facing) information, leave the IP as 0.0.0.0 (listens for requests on all Ethernet interfaces), enter the port number that the WAF service will use to listen for requests, and click Add:
- 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.
- 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.
- Create a new AAA policy by clicking the + button.
- Create a new access control policy named
AddressAdminto identify the user from the HTTP authentication header.
- On the "Configure an access control policy" page, name the new AAA policy
AddressAdmin. Click Create to apply the changes.
- 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:
- 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.
- 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:
- 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.
- 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:
- Leave the resource mapping method as none and then click Next.
- 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:
- Save the settings for the AddressAdmin access control policy.
- Click Commit to save the AddressAdmin access control policy, and then click Done.
- The next page lets you create a Name Value profile to validate name-value pairs in the request. Click Next.
- The next page lets you configure how to handle query strings and cookies. Click Next.
- Click Commit to create the WAF service.
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:
- 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.
- Click the Request maps tab and open the AddressWAF_request rule.
- Click the Profile tab.
- Click the + sign to create a new Rate Limiting object.
- Enter the name
AddressRL. You can change the rate from
500to a different value based on the requirements of your application. Enter a small value such as 3 for testing:
- Click Apply.
- 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:
- Open a Web browser and enter the Web application firewall URL:
- When challenged, enter
fredfor username and
flintstonefor password. Click OK. Make sure that you have logged in successfully and can see your initial page.
- 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.
Websphere DataPower SOA Appliances product page
Product descriptions, product news, training information, support information, and more.
Websphere DataPower SOA Appliances product library
Product announcements, case studies, white papers, and more.
Websphere DataPower SOA Appliances support
A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
developerWorks WebSphere Business Integration zone
For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more.
WebSphere Business Integration products page
For both business and technical users, a handy overview of all WebSphere Business Integration products
Most popular WebSphere trial downloads
No-charge trial downloads for key WebSphere products.
Technical books from IBM Press
Convenient online ordering through Barnes & Noble.