As companies embark on efforts to build loosely coupled service-oriented architectures they inevitably have to tackle the issue of securing their SOA service infrastructure, and many turn to XML security appliances to get the job done.

Why choose an XML appliance to protect and safely expose your SOA data services to customers, partners and software-as-a-service (SaaS) vendors? Without dedicated hardware support it is nearly impossible to withstand denial-of-service attacks and to provide the high availability necessary to ensure data confidentiality, integrity and nonrepudiation.

XML security appliances are typically positioned in the demilitarized zone between two firewalls and become the only device visible to outside clients. The appliance acts as a proxy and performs all necessary security operations, including SSL socket termination, credential validation and data verification.

The XML security appliance is then the only device permitted by the second firewall to establish connections to internal SOA endpoints. Performing security operations outside the endpoints provides a twofold benefit. First, the SOA data service no longer needs to implement any security functions and will not be compromised by hackers. Second, the security infrastructure policy is decoupled from the endpoints and therefore can be easily controlled by the infrastructure security team without having to make changes to the endpoints themselves.

Common functionality

XML security appliances, first introduced in 2000, range in price from US$30,000 to $70,000, and the feature sets vary widely. These are the most common and important features to understand.

• Transport-level security: Inbound SSL/TLS socket termination and outbound SSL/TLS socket initiation with support for server-based and mutual authentication has been one of the cornerstones of Web security and the most popular way to achieve data confidentially, integrity and nonrepudiation

• Application security: WS-Security Standard Support (1.0 and 1.1) is a key standard that defines how to secure Web service messages. In its current version (1.1), the standard defines support for several authentication profiles: Username token, X.509, Kerberos, SAML (an XML framework for exchanging authentication and authorization) and REL (Rights Expression Language, for specifying rights to content, fees or other considerations required to secure those rights) token. It also incorporates support for SOAP messages with attachments.

• Message content inspection and validation: Commonly supported features include the ability to perform schema/(document definition) validation and policy-based content and parameter filtering.

• XML threat protection: Will your appliance protect against hacker attacks that target Web service interface vulnerabilities? Common examples of such attacks include SQL injection, oversized/recursive payloads and schema poisoning.

• Application access management: Also known as AAA (authentication, authorization and accounting), the feature provides protection against unauthorized access and maintains access logging information.

• Single sign-on support: Ability to consume and generate SAML/XACML assertions to facilitate single sign-on with browser artifact (SAML 1.1) and Web services profiles (SAML 2.0).