SOA Gateway

SOA Gateway - The Evolution of SOA and Cloud Computing

2009-12-29T22:01:00.000-08:00

It has been a long time coming. For many years SOA Governance was the industry buzzword that virtually every company employed to indicate that they played in the SOA arena. The term "SOA Governance" was used to describe everything from design time management of test and design artifacts, monitoring, enforcement, UDDI registry storage, SLA expectations, etc. Many of the industry analysts latched onto UDDI as the central technology that would drive the governance initiatives.

The reality of successful SOA deployment turned out to be a different story. Successful SOA was measured on a project by project basis. Feedback from the CIO and CFO level as to the benefits of each project then reinforced the technology decision to invest further in SOA. It is the individual advantages first that lead to the higher level advantages later of investing in SOA. Due to the fractured nature of SOA deployments, it began to become a technology and architecture of multiple domains within an organization. Teams that each were able to show success of SOA did not do so in concert with each other.

That all changed once the adoption of SOA gateway technology began to take hold. SOA Gateways allow for the runtime governance of services and transactions. This in turn provides the means to aggregate the services of an enterprise in one consolidated location and centrally enforce reusable policies with regard to access control, security, and monitoring. This technology has led the way to the recognition of SOA as a true enterprise ROI optimization investment. As a result, the SOA Gateway has now also become what analysts had envisioned for UDDI in the early phases of SOA, which is the central place by which to manage, enforce, and monitor (a.k.a. govern) services and transactions.

Now we come to the age of cloud computing which is the new buzz phrase that has all but replaced "SOA Governance" in blogs, press releases, analysis coverage, and news cycles. This is the next frontier, the new promise of technology. Let's be clear, cloud computing has potential and real promise as a game-changing technology paradigm, but the actual adoption and recognition of this outcome will follow the same path as SOA did to get there.

Consider that SOA as a concept has been around for many years. Software as a service is not a new concept, but the open nature of services extended this concept to SOA. Cloud computing extends this concept further by providing dynamic SaS as lower cost, on-demand services. While the notion is easy to recognize in it's simplicity and elegance, it becomes a little more difficult to map to actual enterprise business use-cases.

Enter the SOA Gateway. This technology has become the central governance broker for transactions among clients and services. By that nature, the SOA gateway already abstracts the client from the service. This abstraction lends itself perfectly to the adoption of cloud based services that can extend the capacity and computing requirements on both sides of the transaction.

The success of Cloud Computing for enterprise transactions will depend on solving the core business concerns of reliability, security, access control, and accountability. It is not a coincidence that these topics happen also to be the core feature set of the SOA gateway industry.

Just as protocol firewalls and web application firewalls paved the way to the adoption of the internet for business communication, SOA Gateways will pave the way to the adoption of cloud computing for the next generation of business communication.

Overview of XML Security Trust and Threat models

2009-10-25T12:51:00.000-07:00

Web Services allow machines to interact over a network via XML and SOAP messaging, and this has proven to be a valuable tool to both businesses and consumers. SOA Gateways, such as Forum Sentry, allows one to securely and efficiently process XML, SOAP and REST-based enabling a secure SOA deployment.

XML and Web Services Security can be categorized into Trust and Threat Models. The Threat Model helps identify both inbound and outbound threats and provide means of remediating such threats. Trust Models ensure that message privacy and integrity and retained while ensuring proper that appropriate authentication and authorization decision are made before letting messages traverse a corporate network.

Threats: Three major threats are Denial-of-service attacks (DoS), Viruses, and SQL injections:

DoS attacks prevent a user, or an organization, from accessing services of a resource that they would normally be able to gain entry to. Although this type of attack can cost time and money, usually there is no information loss involved.

A virus is a program, or a programming code, that replicates itself. Viruses are often found in email attachments, downloaded files, and on CDs. They may erase data or damage the hard drive. When a virus duplicates itself by resending itself as an attachment to an email or as a component of a network message, it is called a worm. There are three classes of viruses: file infectors, system or boot-record infectors, and macro viruses. File infectors attach themselves to program files and infect that program. System, or boot-record infectors, infect code on areas of a disk. Macro viruses are the most common, but they do the least amount of damage. Viruses can use Web services to enter corporate domains by going undetected through SOAP attachments (MIME or MTOM). Since such attachments are Base-64 encoded or maybe encrypted, traditions Anti-virus engines cannot match signatures to detect them

SQL injections are used to gain access to a database or retrieve information from a database. This access is unauthorized and programs and applications are at risk of being attacked. It is easy to defend programs and applications from SQL injections by using simple coding practices or by looking for malicious string patterns used for SQL injections.

Trust: Three major categories of trust are privacy, integrity, and identity:

When it comes to privacy, encryption protects personal information by encoding information. This has to be done so that only the person, or computer, with the private key can decode the information.

Integrity insures that no one tampers with information. Signatures and verification are both part of integrity. Signatures are strings of letters and numbers that represent a signature. The message is scrambled with mathmatical formulas or algorithms. A key is needed to validate the signature. Verification simply validates a users indeed signed a message with his private key.

Identity involves authentication, authorization, access control and tokens. Authentication verifies that information comes from a trusted source. One must know who created the information, as well as be sure that the information has not been modified since created. Authentication works closely with encryption to ensure that there is a secure environment. Authorization is simply controlling the access and rights to resources, including things such as services or files. Access control restricts what a user can do various resources. There are many types of tokens including SSL tokens, SAML tokens, and WS-Username tokens. Properly handing such Tokens both at the protocol and message level is crucial for establishing trust between business entities.

Both trust and threat must be addressed so ensure Web Service security. This is an essential component of information technology since a large amount of information is now located on the internet. Forum Systems has developed products that provide security in the Web Service environment.

For more information about trust and threat, see the whitepaper Solving The Trust & Threat Equation.

How-to establish XML Security using a Network Appliance

2009-06-29T09:50:00.000-07:00

Providing appropriate XML Security is essential in ensuring secure integration across applications. XML makes machine-to-machine communication possible using standard internet communication protocols. The flexibility of using XML to integrate application directly competes with security. Forum Sentry, the leading patented appliance for XML Security enables enterprises to integrate with their trading partners without compromising security.

It is important to note that one of the main focuses of the Sentry XML appliance is, and has always been, XML security. Right out of the box there are many security features enabled by default, and the fact that your clients are accessing Sentry and not your back-end service directly is a major security benefit in itself. Forum Sentry is the industry's only patented XML Security Gateway that is both FIPS 140-2 certified and DoD PKI certified. For a good overview of Sentry's focus on security please click here.

You can also find many whitepapers regarding security around XML and Web Services here. We recommend starting with the "Best Practices in Deploying SOA Gateways" and the "Attacking and Defending Web Services" papers for a good introduction.

There are many features of Sentry related to securing XML that SHOULD always be utilized. These features include:

SSL (with or without Mutual Auth)
XML Encryption/Decryption
XML Signature/Verification
Intrusion Detection and Prevention (IDP Rules)
Pattern Matching
Anti Virus scanning
Identity and Access Control (many different ways to accomplish this)

Below are some recommendations for utilizing common features in Sentry to further increase the security of your services:

Use SSL with all externally facing services. All network listeners should use SSL (HTTPS). Start by enable SSL, and then consider enabling SSL with Mutual Authentication. SSL with client/server auth allows you to verify the client cert (and tie it to a specific user). At the very least, the network listeners should be HTTPS (SSL). For FTP traffic, Sentry supports FTPS (TLS or SSL) and OpenPGP encryption, decryption, signatures, verification.
Use IP ACLs on your network listener policies to only allow incoming traffic from specific IP addresses or IP ranges. If a client tries to connect from an unknown IP range the connection will be rejected.
Tighten existing IDP rule thresholds or add new IDP rules depending on your specific criteria.
Enable Anti Virus Scanning.
Consider creating custom Pattern Match policies to catch specific text strings. This helps to ensure no confidential data is leaked out with the response messages and prevents any harmful XML attacks coming into the service.
Consider using XML encryption and XML decryption with your trading partners. The trading partners would encrypt the request data before sending to Sentry, the request data is then decrypted on Sentry. For response processing, Sentry would encrypt the response data before sending it back to the client.
Consider using Schema Tightening and advanced validation options with your WSDL policies.
Utilize Sentry's built in PKI infrastructure. Create, import, and store all keys related to the security of your services within Sentry. For added PKI security upgrade to the Sentry appliances that include the FIPS Level III HSM.

How to tell if your services are secure?

In addition to the recommendations above for tightening the security of your services with Sentry, we strongly recommend you perform some security/vulnerability/penetration testing of your services hosted on Sentry. You can use SOAPSonar from Crosscheck Networks to perform this testing. This is a great tool for functional and performance testing as well, but there is patented technology focused on security/vulnerability testing that you won't find with any other SOA test tools.

For instance, SOAPSonar includes a Vulnerability mode that enables the user to run scans against your services and report any potential issues - and explain how to fix them! In addition, if you configure SSL, encryption/decryption, or other WS Security features on Sentry, you can use this tool to test these features.

You can download a free evaluation of SOAPSonar here.

XML Gateway Patent

2009-06-15T07:27:00.000-07:00

Forum Systems, the pioneer in SOA / 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:

For more details on this news click here.

Why an XML Gateway should be FIPS Certified - Especially in Federal Agencies

2008-11-17T14:48:00.000-08:00

A FIPS certified appliance provides self-test and a finite state machine, providing network security assurance without risk of compromise. FIPS 140-2 validation of the entire appliance is the only independent validation that can provide assurance that the proper key storage, cryptographic operations, and operational integrity of the SOA Gateway have been met. A number of agencies and private organizations have now made FIPS a core requirement and recognize that just providing HSMs is insufficient and a fully FIPS validated SOA Gateway Appliance should be deployed to ensure the highest degree of robustness, scalability and security in a SOA deployment. For complete article click here.

Introduction to SOA/XML Gateways

2008-11-13T12:30:00.000-08:00

There is an excellent article published by the folks at Forum Systems that highlights the best practises in deploying SOA/XML Gateways within your networks. The article covers the following significant areas:

Service Virtualization and Control
Data-level Privacy and Integrity
Information Flow Control and Audit

This article is a must read for serious SOA/XML architects, Application Integration specialists, Security professional and XML-based application developers.

To Read Article, goto: http://forumsys.com/resources/resources/whitepapers/Best_Practices_in_Deploying_SOA_Gateways.html

Why is an XML Gateway a requirement?

2008-10-21T18:45:00.000-07:00

Much have been talked about this subject. The main two reasons to justify the capital expense on such a device 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 need 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.

The same use case can be done with an XML gateway fronting all the security aspects: SSL termination, signature verification or any other security requirement. The 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 uptodate 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.

Common problems with SOA deployments

2008-09-01T13:06:00.000-07:00

Most large corporations face a common set of SOA deployment issues. Some of the issues are technical, some organizational. SOA is all about encouraging re-use at all levels, from simple operations to complex combinations of operations that form re-usable business operations.

Here are some common problems that we have seen across many deployments:

Security is rarely a concern when enterprises build new SOA systems or port legacy systems into a SOA based environment. If at all, security is introduced as an after thought. Applications are built by development teams, and once they are ready to go into production, the operational folks bring up security concerns and the quick and dirty solution is to "turn on SSL."

Recommendations: Start looking at SOA security issues early on in the development process. Look at security within SOA comprehensively. Consider content-based security, protocol security, access control across operations. Look closely at the sensitive information and who should have access to it.

Identity Management Systems are crucial in SOA deployments. However, Identity Management Systems are designed for Single Sign-On for web site resources, rather than protecting web services operations.

Recommendation: Ensure that your identity systems are extensible and can address SOA specific access control.

Scaling: As new web services come online in your organization securing and monitoring them becomes increasingly difficult.

Recommendations: Make sure you have an XML firewall capable of scaling with your needs. In addition to the XML firewall, you are going to need a monitoring solution, to track capacity limitation and potential outages.

Monitoring the health of your web services security infrastructure is no longer limited to your load balancer pinging your XML firewall. Even though your firewall might be responding to ICMP packets that's no guarantee that your web services are working correctly.

Recommendation: A combination of a monitoring solution and some health checks across the infrastructure. Make sure your health check exercise one or more of your web services operations to make sure that not only the XML firewall is up but also the back end servers that perform the web services operations. All parts of the infrastructure should also be monitored, including databases, syslog servers, identity servers and network connectivity.

People: The single most problematic part of SOA deployment is the people involed in supporting and maintaining the deployments. In the past, firewall configuration and setting is something the IT department handle. SOA deployments present an unique challenge in this regard. XML firewall touch on so many internal system that in most cases not a single person is capable of maintaining the XML firewall by himself or herself. This is could be one of the most expensive aspect of a SOA deployment.

Recommendation: Make sure you assign a single person responsible for your XML firewall. This person does not necessarily need to know how to configure every aspect of the XML firewall, but it should be responsible for coordinating all aspect of deploying the configuration. Whatever you do, do not leave the XML firewall configuration on the hands of the IT department!!! In most cases the folks do not have the technical expertise for maintaining, and it requires help of the web services developers for properly manage the devices. In addition, avoid too many people having access to configure the device. It is best to have a small group of people that can make changes.

More to follow ....

Techniques in Attacking and Defending SOA Web Services

2008-06-26T19:02:00.000-07:00

A good resource for those interested in the benefits of deploying a SOA Gateway. This is hands-on demonstration of attack vectors for SOA and Web Services and implementation of defense strategies using a SOA Gateway. Techniques include live examples of:

SOAP based SQL Injection Attack
Denial of Service Web Service Attack
XSD Mutation
Identity Discovery

Attack vectors are demonstrated using Crosscheck Networks SOAPSonar testing and diagnostics product and each attack is explained and mapped to the published CAPEC: Common Attack Pattern Enumeration and Classification system.

The Forum Systems Sentry SOA Gateway is shown as the central defense mechanism for back-end services with live data transaction examples and defensive actions.

View the demonstration here.

Virtues of WSDL Virtualization

2007-08-17T09:27:00.000-07:00

WSDL virtualization is the ability to create a virtual WSDL from one or more predefined WSDLs files. Typically, WSDL virtualization takes place across multiple back-end systems that expose their operations through WSDL documents. An intermediary gateway sits between the producer and the consumer and aggregates the WSDLs. Based on policies enforced on the gateway, operations are exposed to the consumers. A sample deployment is shown below.

The virtues of WSDL virtualization include:

Security: The virtual WSDL can exposed or hide some of the operations from the original WSDLs. The WSDL endpoints are cloaked with only the intermediaries endpoints being exposed.
Consistency: Virtualization allows to select operations from multiple WSDLs and exposed them to clients as a coherent single WSDL.
Productivity: The main benefit of virtualization is to be able to mix and match operations without having to copy and paste parts of the desired WSDLs into new WSDL files. It allows a customer to be able generate a library of all the operations suported on its organization and only exposed the ones required for a particular customer.

Some of the challenges of WSDL Virtualization addressed by Sophisticated SOA Gateways, such as Forum Systems Sentry include:

Resolving different schemas that share the same namespace.
Multiple schemas might have different constraints for the same element, that might be incompatible.
Exposing the list of WSDLs that developers should be working on. Although external trading partners typically require a single WSDL, internal developers work with multiple WSDLs. A list of WSDL needs to be retrieved from the SOA Gateway to better manage developers working across multiple WSDLs

WSDL Virtualization is a crucial part of deploying SOA. The vices of free-for-all operations can quickly set chaos within a SOA deployment that can only be controlled through SOA Gateways that provide strong WSDL virtualization.

Qualifying Your SOA Gateway's Horse Power

2007-08-12T06:59:00.000-07:00

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 SOA Gateway community is not immune to this indulgence. I have to admit, even I am guilty of committing this sin sometimes.

In the SOA 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, SOA 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 SOA Gateway is schema validation. This task validates the the structure of incoming and outgoing SOAP/XML messages. The performance of a SOA 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 SOA Gateway.

Common SOA Gateway Deployments

2007-08-06T15:20:00.000-07:00

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

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.
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.
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 SOA Gateway deployment.