Forum Systems latest XML Gateway targets SOA Federation

Looks like Forum Sentry, the pioneer and leader of XML Gateway and XML Firewall technology has announced its latest product that now addresses the growing need for handling not just XML/Web services traffic, but also HTML/Portal traffic. From a technology standpoint, this is not a revolutionary jump, but a gradual evolution of the XML Gateway that now handles HTTP/HTML-header information, which is by far easier than looking deeper into the XML packets. However, the business implication of this is significant since companies can now use a single platform for HTML and XML processing.

Continuing to set the benchmark for securing Web services, key new capabilities available via Forum Sentry include:

• HTML Portal Virtualization – Deployed in a “proxy” setting, Forum Sentry removes the identity and security burden from Web sites and portals. Leveraging Single Sign On (SSO) functionality across existing infrastructures, Forum Sentry’s non-intrusive, agentless design accelerates security and identity on a dedicated device – without requiring code changes to backend Web applications and services, or additional capital expenditure costs.
• Central Cookie and SAML Processing – Forum Sentry authenticates and authorizes both portal- and Web services-related identity tokens – the cornerstones of Federated SOA. Credentials are shared – regardless of where the services reside – throughout the entire transaction, producing an enhanced, seamless user experience without compromising security.
• Federated Two-Factor Authentication – Promoting greater security, Forum Sentry requires two pieces of information for identity verification of internal and external partners. It removes the complexities so often associated with token sharing across portals and Web services, while still enforcing the highest levels of authentication and authorization.
• Protocol/Document Attribute Mapping – Promoting greater ease of use, HTTP/HTML header information can be mapped into messages and documents. User information from HTTP can be transferred into a SOAP or XML message for usage elsewhere in the network – independent of protocol – enabling SOA Federation across both XML and HTML traffic.

For more details, see: Forum Systems Drives SOA Federation for Enterprises and Government Organizations

XML Flaws are Pervasive

Finally! What companies such as Forum Systems pioneered a defensive layer for through its XML Gateway product, Forum Sentry, and Crosscheck Networks invented for identifying XML Security vulnerabilities thorough its XML/SOAP pen testing product, SOAPSonar is now becoming mainstream.

Washington Post published an interesting article highlighting such XML-based vulnerabilities in a recent article titled XML Flaws are pervasive. This article highlights issues that Forum Systems introduced in early 2004. See white paper titled "Anatomy of a Web Services Attack." This paper cements Forum Systems as the pioneer in identifying a new class of security vulnerabilities exposed via XML/SOAP/WSDL-based technologies.

http://voices.washingtonpost.com/securityfix/2009/08/researchers_xml_security_flaw.html

Qualifying your XML Gateway Horsepower

Often in our tech industry there is a penchant to spout off performance numbers without qualifying the metrics and conditions under which these numbers are derived. The XML Gateway community is not immune to this indulgence. I have to admit, even I am guilty of committing this sin sometimes.

In the XML Gateway world, performance cannot simply be defined in terms of transactions per second (TPS) due to complexity of a message transaction and the task policy of the gateway. As a result, XML Gateways today always specify a specific task (i.e XML transformation, WS-Encryption) and the associated TPS. However, this type of metric still falls short of fully expressing the true performance metric of a SOA Gateway. For example, a common task that is staple of every XML Gateway is schema validation. This task validates the the structure of incoming and outgoing SOAP/XML messages. The performance of a XML Gateway when performing validation is often expressed in terms of Schema Validation TPS.
This is simply not sufficient. Further qualifiers that should be applied to schema validation performance numbers are as follows:

• What is the size of the message?
• What transport protocol (HTTP 1.0, HTTP 1.1, MQ etc) was used to derive the numbers?
• Was the deployment in proxy mode or was it in service mode?
• How many clients were used in generation of load?
• Was the validation task performed on both inbound and out bond messages?
• How complex was the message structure and its associated schema (i.e n-dimensional arrays, abstract types).

The last bullet is a real challenge and it really affects the validation performance of a gateway.
Unless, these qualifiers are resolved, the numbers are subjective at best. Maybe one day we will learn some lessons from the automotive industry to really define a true metric in defining performance of each task in a XML Gateway.

Frequent XML Gateway Uses

XML Gateways are becoming standard in enterprise SOA deployments with the following common themes:

1. Identity mediation is the first step for the majority of SOA Deployments. Identities come in may shapes and sizes represented at both the protocol level (e.g., HTTP Basic Auth, SSL Mutual Auth) and message level (WS-Security tokens X.509, SAML, etc.). Even if an enterprise successfully standardizes on a single identity representation, it cannot dictate how it's trading partners should represent its identities. Thus, inditites need to be accepted in many forms and changed to a single internal representation - that is if everyone within an organization can agree to a standardized representation. Most likely, even internally, more than one identity representation exists.
2. XML Firewalling is essential to ensure that information is checked before it makes it to the back end application server. The XML should be clean so that the backend server can safely process the message. Even more significant is the need to ensure that the SOA Gateway checks for information leaking from the corporation. This includes preventing sensitive information such as Credit Card Holder information from being compromised, as mandated by the PCI Security Standards Council.
3. Data Integrity and Privacy using content based signatures and encryption ensures that the message is not tampered with and that any part of the message can be encrypted granularly using standards such as WS-Security.

Other items such as Data Mediation, enrichment, transformation and archiving are also commonly enabled in a XML Gateway deployment.

Why is an XML Gateway a requirement?

The main two reasons to justify the capital expense of an XML Gateway are performance and security. When the enterprise deems those two reasons relevant it is a no-brainer to make the XML gateway a requirement.

Now let's take a simpler scenario where performance is not a problem and security is meant to be accomplished using SSL. I claim even in this scenario purchasing a dedicated server is a wise investment. Let's assume you intent to invoke web services from multiple partners. The number of partners could potentially be on the thousands. As is the case, currently most of this partners do not have any web services as of yet. So they start as usual writing it from scratch using something like .NET. These projects tend to be low key and usually prototypes, so the use of a gateway is not even considered.

Most scenarios, in addition to using SSL mutual auth to secure the connection and authenticate the client will use some sort of XML security such as signature verification. This will require the developer coding the business case to write the required code for the signature verification. This is no trivial task to get done correctly. Even with all the help the .NET framework gives you, there are many caveats the developer will have to be aware and most likely will not have time to properly code for. I see several problems with this approach:

• The security of the deployment solely relies on the time and expertise of the developer writing the security piece. In most cases, verifying the signature is just a small piece of the puzzle, quite irrelevant to the business case. It is a necessary evil that needs to be done, but does nothing for the bottom line of the company.
• Debugging the signature verification code is time consuming. Why bother re inventing the wheel when they are companies that specialize in doing this sort of thing?
• The private keys are most likely sitting on the hard disk not properly secured. Whenever a new web services comes online the procedure will have to be repeated. This model is not scalable and at the end not cost effective.

Such use cases can be readily handled with an XML Gateway fronting all the security aspects: SSL termination, signature verification or any other security requirement. The XML Gateway centralizes all security aspects so that your developers can concentrate on the business case at hand. You can rely that your web service is properly secured without having to trust the individual ability of each developer. After all, the gateway is backed by a company so their reputation is always on the line. Private keys and certificates are on a central secured location not spread around in web servers around your organization. The Gateways are kept up-to-date with the security standards, no need to go back to every one of your coded applications to update the security aspects of it. At the end, you will have save money and time for your company and ensured the Web Service deployment is secured.

XML Gateway Patent

Forum Systems, the pioneer in XML Gateways became the first network appliance to be issued a Patent for XML security functionality.  This issued patent 7,515,333 has a significant impact on the XML Gateway market landscape and locks Forum Systems position as the pioneer in the XML Security appliance marketplace with defensible protection for XML Security hardware related Intellectual Property.  Vendors in this space include:

1. Forum Systems
2. IBM Datapower
3. Cisco
4. Intel
5. Vordel
6. Layer7

For more details on this news click here.

XML Gateway: Best Practices, Requirements and deployment Strategies

XML Gateways are a great IT component for managing information flow between your enterprise and your trading partners.  They provide the required functionality, such as:

• Identity bridging (e.g., from HTTP Basic Auth to SAML)
• Transport mediation (e.g., between HTTP and MQ Series)
• Protocol and content based security (e.g., HTTPS, WS-Signatures, WS-Encryption)
• Message inspection (e.g., for SQL Injection, Viruses, and other malware)
  
• Interface Virtualization
• Transformation, Schema Validation

Such functions make is easy and cost effective for enterprises to integrate with their trading partners is a secure manner.  Here's a good article for best practices using XML-Gateways.

http://forumsys.com/resources/resources/whitepapers/Best_Practices_in_Deploying_SOA_Gateways.html