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 $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).
No single solution works for all enterprises. The organizational business requirements and the existing IT infrastructure considerations should drive the selection process. Five key areas should be considered.
* Hardware: Most companies will need to weigh their need for speed against the cost considerations of customization and performance enhancing features. For example, some appliances are built on standard server platforms, while others take advantage of custom designed router-style hardware. Vendors of customized solutions tend to be slower to adopt advances in processors and chipsets, which may be required for business process optimization.
* Support for security standards: The degree to which the common set of standards is supported varies between vendors. It is not uncommon for vendors to offer partial support for certain security standards. For instance, SAML assertion consumption is almost universally supported but SAML generation is not. Vendors also get picky about what SAML assertions they support (most support authentication and only a few support authorization and attribute).
* Extensibility and ease of integration: No appliance can provide 100% of the required functionality out of the box. Therefore, it is important to look at extensibility in terms of the scale and effort involved. Common extensions include enabling new custom data sources, creating custom business rule processing tasks and adding support for a communication protocol. Ask whether or not the XML appliance has features commonly found in enterprise service bus (ESB), such as content-based routing, protocol bridging and Web service aggregation, to maximize the overall benefit of the appliance investment.
* Scalability and performance: Make sure the role defined for the XML security appliance fits into the sweet spot of the product functionality. For instance, if the appliance is supposed to terminate a large number of inbound SSL connections from the browser, it should not have substantial limitations on the size of its connection pool. Or if the appliance’s main role is to perform XML threat protection and data validation, choose an XML appliance with a hardware-based XML processing capability.
* Integration with IT infrastructure: Make sure your appliance will integrate smoothly into your IT ecosystem. Every organization standardizes on a set of user credential repositories, infrastructure monitoring and management tools. The XML appliance support of a specific IT infrastructure can vary widely.
If you map your business and IT needs against the vendor’s features and follow a structured process for vendor selection, you are practicing safe SOA and capturing the best of both worlds – flexibility and security.
Khurgin is an SOA practice manager for Acumen Solutions, a business and technology consulting firm. He can be reached at ikhurgin@acumensolutions.com.
