Intel’s SOA Expressway is a software package that allows for the many different options in controlling the flow and security of web services throughout an organization or even those published to external consumers through a DMZ. In many instances, especially for public interfacing web services, it is essential to have some type of filtering (also called reverse-proxy) of requests from a consumer of a web service and this is the specialty of SOA Expressway and how it is used to protect web services. In addition to the built-in security features provided by a proxy workflow, proxy workflows within SOA Expressway can contain Content Attack Prevention (CAP) policies.
There 3 essential parts to a standard web service gateway proxy workflow which include Receive, Invoke, and Reply. This workflow can be synonymously called the BPEL or Business Process Execution Language. The Receive action actually takes in the SOAP request for processing, the Invoke will send the call to the web service and the reply can send the response back to the consumer of the web service. But there are many other activities that can be configured for a web service to provide increased security and even actions based on what is returned from a prior step in the workflow. But for a simple overview, below is a display of a workflow using some of the tasks necessary for configuring a CAP Policy. A CAP policy is a comprehensive policy that fits into the message validation category of securing web services. CAP offers mitigation against both structural XML threats, such as coercive parsing and XML fuzzing, and semantic threats in the message payload. In a previous blog on SOA Expressway, I described some of the threats that a CAP policy can mitigate. More generic terms for these type of attacks include Canonicalization, Cross-site scripting, SQL injection, XPath injection, and XML bomb.
The following image is an example of a workflow created using the Intel SOA Expressway Designer tool. The CAP policy is placed in position to evaluate the received message.
The CAP policy is configured within the SOA Expressway Designer tool. This configuration area can customize the mitigation for many different types of attacks using a CAP policy. The CAP policy can be configured to reject any message request that contains violates the policy.
The following options exist to configure the CAP policy.
Although this type of security feature does not cancel out the need for proper security development processes, having a CAP policy can provide another layer to your security defense-in-depth strategy by applying restrictions to what can be allowed to pass through to the web service. This is especially helpful if a newly discovered xml based threat is known to have characteristics such that can be evaluated with a CAP policy. Another great benefit to the CAP policy within SOA Expressway is that a CAP policy can be assigned to many different workflows so that it can be changed in one location and utilized by many different workflows. Of course, this should be after it has been thoroughly tested in a test environment.
Other valuable features that can provide greater security within SOA Expressway include XML schema validation and global error handling within the BPEL workflow. There are some great video tutorials available at http://www.dynamicperimeter.com/videotutorials