Product Review

Security is important. Anyone in the business of designing, developing, hosting, or managing business applications understands this fundamental statement. Web services present unique challenges such that the integrity and security of the content of the exchanged documents is just as important as the integrity of the communications link between the trading partners.

Addressing this broad definition of Web services security is the Forum XWall Web Services Firewall from Forum Systems. Within a network topology, it serves as the entry point to an enterprise's collection of Web services and is available as a hardware or software component. As its name implies, the product serves in a traditional firewall capacity such that it may be used to protect resources from external requests. However, it also provides functionality that addresses the security of the content passed between the host and client.

The Forum XWall system is a highly configurable security tool that provides several components enabling secure Web services. Its network security capabilities include PKCS keys, public certificates and SSL, Access Control Lists, IP filtering, and custom error-handling templates. From a Web services point of view, the security functionality includes intrusion detection, WS-I validation, request filtering, and system alerts. This review looks at the software version of XWall.

Securing Web Services Network Perspective
The firewall provides a Web-based interface for configuring all security parameters. All settings are grouped into the Administration, Resources, and System categories. The Administration section contains the Getting Started instructions (see Figure 1), monitoring functionality, and general gateway policies. The Resources section is where administrators set up the key repository, SSL security policies, access control settings, and error templates. The System section includes settings for the operation of the firewall itself, logging, and configuration import/export.

Basics
In the most basic setup, there are two main steps to securing Web services:

1. Create network policies
2. Establish Web services policies

Network policies, or HTTP server policies, are either local or remote and provide the channels through which network data travels. Local policies protect resources from incoming traffic. Remote policies act as proxies to services on tertiary systems.

The local policies establish the ports that will accept incoming traffic and provide the network-level security functionality. There are five components to this listener when working with the HTTP protocol:

1. List of client IP addresses allowed to access services
2. Protocol used to access services - HTTP or HTTPS
3. Listener IP address, port, and whether basic HTTP authentication is required
4. The Access Control List to apply
5. The template used for error messages

Once incoming network traffic has met the requirements of the local policies, it is passed through to the remote policy. Remote policies are used to configure access to the actual Web services applications hosted on additional servers. There are three components to this policy when working with the HTTP protocol:

1. Protocol used for outbound communications - HTTP or HTTPS
2. The IP address or hostname of the machine on which the desired services exist along with the port and basic HTTP authentication settings
3. A flag indicating whether or not the response from the remote service is to be processed. When turned off, the remote service's response is returned to the calling client unchanged.

For this review, I have established a basic local policy. It establishes a listener on port 8080, restricts IP addresses to a segment of my network, uses the HTTP protocol, and requires basic authentication. I've associated a simple Access Control List with this policy that provides read and execute permissions to a group of one user. I will discuss the remote policy later.

To demonstrate error conditions presented by the local policy, two SOAP messages were sent; one from an IP address that falls outside of the security policy and one with incorrect credentials. As expected, the server responded respectively with 403 and 401 HTTP status codes.

Access Control Lists
As I mentioned in the previous example, Forum XWall supports Access Control Lists to restrict user activity. Users may be defined directly in the Web console or may be imported from an LDAP server. For users from an LDAP server, passwords may be imported in either MD5 or SHA encrypted format. Alternatively, system administrators may choose to have user passwords checked dynamically against the LDAP server at authentication time. Once created or imported, users may then be added to groups, which in turn are assigned to various Access Control Lists. Lists are easily assigned to local server policies during the setup of each policy.

Securing Web Services: Content Perspective
Not only does the Forum XWall Firewall provide network level security, it provides security at the Web services message level. Content is protected via WSDL policies, which are derived from the WSDL documents of the services that clients will ultimately access. Essentially, the WSDL file of the desired service is imported to Forum XWall. As an example, I've imported a WSDL file for a temperature service from Xmethods.net. Once the document is imported, the administrator must choose the listener policy that should be applied to this service. For this example, the policy defined earlier will be applied. The next step in the process is establishing the remote policy for the service.

Remote policies are established to provide the pass-through to the actual Web Service to be executed and have similar configuration parameters to local policies. When working with Web services that require basic HTTP authentication, the administrator may choose to propagate credentials provided initially by the client if challenged, or to use a predefined set of credentials.

Once the basic policy is established, Forum XWall's key strengths are available to the administrator. At this point, any operation defined in the imported WSDL file may be enabled or disabled to calling clients. Additionally, separate ACLs may be applied to each operation. This provides for a very flexible access control policy for all configured services.

Forum XWall also addresses the security and integrity of the content of SOAP messages exchanged between the client and service. One of the key features is the ability to perform runtime validation of SOAP messages against the WS-I Basic Profile 1.0 specification. For each WSDL policy in the system, WS-I profile tests may be selectively applied to the messages as they pass through the firewall. For any exchange including a document that does not fulfill the tests configured, a SOAP fault is generated and sent to the calling client.

Another powerful feature of the firewall is the Intrusion Detection and Prevention (IDP) rules that may be applied to WSDL policies (see Figure 2). By default, the firewall comes configured with rules to detect authentication failures, invalid HTTP messages, SOAP documents not conforming to any configured WSDL specifications, document processing errors, and documents that exceed a predetermined size.

After all security parameters have been set within a WSDL policy, the service must be made available to calling clients. This is done by publishing a new WSDL document derived from the local, remote and WSDL policy settings configured. Forum XWall provides the option to export the WSDL document as a file or to upload it to a UDDI server.

As an example, I've configured the temperature service with a document size rule to reject any message over 1 byte. All calls to the service received SOAP faults indicating the error. For even higher levels of security, the system may be configured to fail silently and not return a response to the calling client at all.

Summary
Forum Systems XWall Web Services Firewall is a powerful security solution targeted to Web services. The features covered in this review represent only a small portion of its overall capabilities. The system effectively addresses the problem of securing Web services applications from both a network and content perspective. Overall, this is a very solid product that should be considered for Web services applications.

Forum Systems
Company Info
Forum Systems
45 West 10000 South, suite 415
Sandy, UT 84070
801-313-4400
Fax: 801-313-4401
Toll Free: 1-866-333-0210
sales: twise@forumsys.com