Learn best practices and common deployment scenarios of XML Gateways and why they are an essential component of a secure, robust and scalable SOA deployment..

I. OVERVIEW

Modern Service Oriented Architecture (SOA) enables service consumers and producers to exchange messages over ubiquitous standards such as XML, SOAP and JSON. Typically, companies embark on SOA projects for system-to-system integration within their corporate domains as well as with external trading partners. The success of a SOA deployment is measured by the level of reuse of producer services. A well thought out SOA is flexible, loosely coupled and nimble and enables consumer applications to rapidly integrate with published producer services. The driving force of a successful SOA to reuse producer services is usually at odds with security. Integration flexibility and security typically pull in diametrically opposite directions. Integration pulls corporations towards "opening up" internal systems for other systems to call into whereas security pulls a company towards "locking down" business information through access control and data privacy. For a successful SOA deployment, ease-of-system integration without compromising security is paramount. Overly strict security models can eliminate the ease-of-integration advantage and an overly open SOA deployment with little or no consideration for security is a recipe for disaster, especially where sensitive and valuable corporate data is involved. XML Gateway products such as Forum Sentry (a FIPS and DoD Certified hardware appliance) and Radware AppXML provide the necessary balance between rapid integration and security that results in a successful SOA deployment.

An XML Gateway is a core infrastructure component of a SOA deployment with the ability to integrate services securely. Typically deployed as a hardware appliance, an XML Gateway seamlessly controls access to services, protects information through data-level encryption, ensures the integrity of a message through signatures, and controls corporate information flow. This article covers XML Gateway deployment best practices, benefits and requirements with a focus on service virtualization, message privacy and integrity, and message control and auditing.

II. BEST PRACTICE: ENABLE SERVICE VIRTUALIZATION AND CONTROL

Description: Service Virtualization - the most important best practice of a SOA - is the ability to create a virtual service from one or more Web Services Description Language (WSDL) files generated by producer applications such as application servers, RDBMS, CRM and ERP systems. As shown in Figure 1 below, service virtualization across multiple producer systems is accomplished through an intermediary XML Gateway that sits between the producer and the consumer. Instead of directly importing services from a variety of producer applications, consumer applications can import virtualized services from an intermediary XML Gateway that aggregates and consolidates multiple back-end producer services into a single WSDL and a single entry point. Service virtualization enables enterprises to expose only specific business services required by a consumer rather than exposing all services from producer applications. On requesting a WSDL from the intermediary XML Gateway, the consumer is presented with a set of virtual services that it is allowed to access. In the sample deployment shown in Figure 1 below, the "Internal" consumer is authorized to use services A-C and D,E from the producer Application Server and Business Application respectively. However, the "External" consumer, perhaps a supplier, is only allowed to use services B and F. Thus, an XML Gateway acts as a central point of control that cloaks and safeguards producer services through access control policies and through virtualization only shows the services available to a consumer.

Benefits: Enabling Service Virtualization by using XML Gateways has significant benefits including:

Requirements: XML Gateways require industry-hardened WSDL and schema parsing to import, aggregate and publish complex WSDLs generated from a variety of application servers, RDBMs, and business applications. For enterprise-class service virtualization, an XML Gateway is required to have the following essential features:

Deploying Service Virtualization with granular access control is crucial for a scalable SOA. The vices of free-for-all services can quickly set chaos within a SOA deployment. An XML Gateway can control and manage an increasingly complex SOA deployment through service virtualization. Identity integration goes hand-in-hand with service virtualization. Leveraging existing identity infrastructure with service-level access control is the most crucial best practice of a SOA deployment. The quality of an XML Gateway integration with identity systems along with the gateway's performance optimization features - such as intelligent credential caching - will determine the overall performance of a SOA deployment.

III. BEST PRACTICE: ENFORCE DATA-LEVEL PRIVACY AND INTEGRITY

Description: Data-level privacy and integrity is the cornerstone of enterprise-class SOA. With SOAP/XML encryption and signature, confidentiality and integrity remain "always on" by being independent of transport protocols. With security now living within the SOAP/XML messages, it does not matter if the transport pipe – HTTP, FTP, JMS – between Web service consumers, producers, or intermediaries is SSL enabled.

The protocol independent nature of SOAP/XML-based messaging within a SOA decouples the messages from protocol security such as SSL. In a SOA, messages traversing the enterprise may do so over non-secure protocols such as FTP and JMS. To ensure that a message retains its privacy and integrity, security has to live within the message through data-level encryption and signatures. By using WS-Security (an OASIS security standard), messages can be granularly encrypted/decrypted and signed/verified for ensuring privacy and integrity at the data level, independent of protocol security.

Deploying an XML Gateway to handle data-level encryption/decryption and signature/verification is a widely used industry best practice for ensuring strong privacy and integrity. Figure 2 below shows a typical SOA Gateway deployment for verifying and decrypting inbound messages from a consumer that has first encrypted and then signed the message before sending it out to the producer services. The message is intercepted by the SOA Gateway that performs a signature verification on the message to ensure that it has not been tampered with and then decrypts the message before sending it to the back-end producer application. The SOA Gateway takes away the burden of signature verification and decryption from the producers and provides a central location for maintaining security policies.

Requirements: SOA Gateways have to be secure, robust, performant and highly interoperable in an enterprise-class environment where many internal and external systems are exchanging messages. For deploying privacy and integrity, an XML Gateway must meet the following requirements:

Requiring developers to intertwine security policy code with their services is a failing long-term strategy. It puts tremendous maintenance burdens on the service implementation and exposes SOA to security risks as well as interoperability pitfalls. Separating security policies from a service implementation and centralizing such policies using an intermediary XML Gateway ensures that the security holes are not inadvertently introduced by developers and the SOA deployment can be built up rapidly by decoupling security processing tasks from the producer services.

IV. BEST PRACTICE: CONTROL AND AUDIT INFORMATION FLOW

Description: In a well-built SOA, business information flows effortlessly between applications. The applications are not only internal applications - one of the key benefits of SOA is that external partner applications can also be readily integrated with internal corporate systems for process automation. This ease of information flow facilitated by a SOA puts significant message control and audit requirements on the infrastructure including message filtering and message archiving requirements. Message filtering ensures that nothing malicious enters a corporation through SOAP/XML channels. Message filtering also prevents "information leak" by ensuring that classified corporate information such as financial and customer information or top secret military/defense information is not stolen or inadvertently sent over outbound SOAP/XML messages. In addition to message filtering, corporations are mandated by regulatory requirements to archive and store business transactions for auditing purposes. Regardless of regulatory mandates, it is a widely instituted best practice to control inbound and outbound messages through filtering as well as archiving selected messages for auditing purposes. As shown in Figure 3 below, an XML Gateway provides filtering and archiving functionality by intercepting SOAP/XML messages sent between consumers and producers. The SOA Gateway intercepts and filters messages by performing deep-content inspection of the SOAP/XML messages. Selected messages can then be archived to an external RDBMS as a complete message or by extracting parts of the messages.

Benefits: Enabling information control through an XML Gateways has significant benefits including:

• Consistency: By centralizing message filtering and archiving policies, a consistent set of rules can be enforced across a SOA deployment for allowing or denying messages in and out of a corporate network based on message payload. Messages can also be archived consistently based on business data within a message.
• Security: SOA Gateways act as SOAP/XML Firewalls that inspect inbound messages for malware and only let clean messages through. Through deep content inspection, SOA Gateways provide security by ensuring that malicious content is kept out and sensitive information is prevented from leaving corporate domains.
• Productivity: Deploying an XML Gateway removes the burden of building filtering and archiving functionality into consumer and producer applications. With simple, code-free policy authoring for message control and archiving, SOA Gateway administrators can rapidly author policies freeing developers to focus on building business functionality.

Requirements: SOA Gateways have to filter, control and archive messages between consumers and producers seamlessly for messages traversing a SOA. For deploying filtering and archiving, an XML Gateway must meet the following requirements:

• Bi-directional Message Control: Both inbound and outbound SOAP/XML messages have to be handled by the SOA Gateway. Typically, inbound messages are checked for malware, validated and then archived to an off-board RDBMS. Outbound messages are usually checked for sensitive information before they are permitted out of the corporate domain.
• Granular Message Capture: SOA Gateways should have the ability to capture full messages and store them in an external database and also have the ability to select any element-level information from a SOAP/XML message and store this information in the database as well.
• Flexible Configuration: SOA Gateways should provide a high degree of flexibility in configuring policies for filtering and archiving messages. Message should be selected for filtering and archiving on any criteria driven from message content. SOA Gateways should be able to archive messages on arrival, at any stage of processing such as encryption, signature or message enrichment and then archive processed messages again so that multiple snapshots along the message processing may be captured for auditing and analysis. One common best practice is to sign and store all inbound and outbound messages for preserving a detailed message trail.

SOAP, XML and JSON messages can contain complex content including binary attachments that should be scanned before allowing the messages to reach corporate back office systems that handle essential business transactions. Similar to email systems that check for message size and content, SOA Gateways should be deployed in a network to ensure that only good messages are permitted in and that sensitive information that is not authorized to leave a corporation are prevented from leaking out of corporate boundaries. Messages should be signed and stored through a robust archiving process for ongoing auditing and data analysis.

V. CONCLUSIONS

An XML Gateway is a core infrastructure component of a SOA with the ability to integrate services securely. Typically deployed as a hardware appliance, an XML Gateway seamlessly controls access to services, protects information through data-level encryption, ensures the integrity of a message through signatures, and controls corporate information flow. An XML Gateway enables SOAP/XML messaging across a variety of transport protocol such as HTTP, MQ Series, FTP, or JMS with protocol-mixing amongst the protocols. In most deployments, SOA professionals choose to use SOA Gateways as hardware-based network appliances primarily for the following reasons:

SOA Gateways add significant productivity to project teams by providing code-free configuration of policies and by freeing up development teams to focus on building core business functionality instead of developing code for security policies, message control and service aggregation. Enterprises serious about cutting costs and increasing revenue through service reuse and rapid system-to-system integration must deploy a robust, secure and flexible SOA Gateway for efficient message processing.