Truth in SOA

I recently noticed this great article on XML appliances published in March 2010. The thing is, I didn't see any mention of Intel(R) SOA Expressway, which is the modern incarnation of the hardware XML gateway brought to market by Sarvega as early as 2000. At Intel, we call this product a service gateway, which can be thought of as a higher-performing, more flexible gateway that more closely matches current performance, extensibility, and data-center trends compared to its earlier hardware only cousins.

I think the author did a great job of mentioning some of the salient points regarding XML gateways, such as the need to push policy enforcement to the edge to simplify coded-in security (decoupling) and the need to provide XML acceleration for complex XML tasks such as transformation, validation, and XML security. He also alluded to some current limitations found in the IBM DataPower appliances:

But as powerful as IBM's XML appliance is, there is always room for improvement. One area where Iocola said the devices have trouble is handling large messages. To remain efficient, he said, the appliances need to offload messages approaching 2 GB to other components.
 
I also like the author's distinction between an ESB and an XML gateway, as this is often a point of confusion. Specifically, the author mentions that a gateway "doesn't host services", and this is true for traditional gateways such as IBM DataPower, but it doesn't have to be the case with a service gateway like Intel(R) SOA Expressway. I would also add that a big distinction between an ESB and gateway is that the ESB doesn't provide edge security protection or high-performance XML processing. For instance, ESBs typically don't have denial of service protection, content scanning, or message throttling. These tasks are more closely aligned with an edge security product such as an XML gateway.

So, what is the difference between a traditional XML gateway and a service gateway? Let's summarize a few points as follows:

• It must support a high performance virtual form factor. This means that performance of the XML gateway cannot require any customized hardware, such as special XML boards or chips.
• It must be extensible for new business logic and security processing. Enterprises cannot wait for hardware refresh for the vendor to add custom processing
• It must support all styles of services, whether based on REST, SOAP or even custom proprietary services based on custom protocols.
• It must scale XML processing on cheap commodity hardware. In this case, Intel(R) Multi-Core servers come to mind but AMD is also an option
• It must not require any specialized coding knowledge, such as deep XSL knowledge, extension functions or an army of developers. After all, if it did you would just invest in writing more code
• It must support non-XML data. While we can all hope that all companies will move their data-sets to 100% XML, it's just not a reality we can count on.
• It must support a wide ecosystem of middleware and security vendors for interoperability and integration allowing for a best-of-breed application.
• It must offer a physically secure form factor running on a well-known operating system with audit able patch levels rather than a custom appliance O/S subject to security by obscurity

Another way to think about a service gateway is that the product category is trying to bring more value to the security architect and developer in the data-center. If you are currently using an XML gateway and notice that many of these requirements aren't being met, maybe it's time to look at a service gateway such as Intel(R) SOA Expressway?

I've spent the last two weeks traveling around to two interesting conferences. One was Microsoft TechEd, where I gave an interactive session on Intel(R) SOA Expressway and the other was JBoss World, where I got a chance to expose the product to a number of JBoss developers and system administrators.

At each of these conferences, I expected to see more of a homogeneous crowd. That is, one would expect a mostly .NET crowd at the Microsoft conference and mostly an open-source or Java crowd at the JBoss conference, and while this is generally the case, developers and architects seem to have grown a much higher tolerance for alternative languages and technology stacks. Issues of “religion” toward a single vendor or technology appear to be fading somewhat. I think this is partly due to the amount of inorganic growth that companies are experiencing, mostly from buying up other companies and having to integrate their middleware stacks.

In these inorganic growth scenarios we have a security architect or developer faced with multiple applications written with products from many different vendors. Most of the time this is a security nightmare scenario: You may have a development team well-versed in coding in security for one language, say Java, and now have to replicate that effort on a completely different middleware stack, say C# or PHP. Worse, as inorganic growth continues, it’s like rolling the “middleware dice” to find out what new technology stack will appear on the scene. In this scenario, you can only scale the security of your application as fast as you can train your security architect to be adept in the “in’s and “out’s” of the particularities of each vendor product – and this is not a risk adverse strategy for any company.

If we step back and look at the problem, the XML gateway such as Intel® SOA Expressway offers an elegant solution. It is the only conceptual model whose success turns on simplifying the security infrastructure by removing coded-in security. What? Yes, that is correct. To use the proxy model for security successfully you have do one thing: turn off the security processing in your middleware stack and force your developers to become application developers and not security architects.

Does this sound backwards? Coded in security is hard to manage, maintain, monitor, audit and change. You are tightly coupled to the subject-matter expert that wrote the code and that person may have left the team after the “inorganic growth” event that caused you to have to deal with this new application. Do you want to find out which version of WS-Security you are really using? Check the code. Want to find out if you are processing X.509 certificates with CRL processing turned on? Check the code. Are we accepting signed requests? Check the code. Are we protecting against SQL injection attacks or performing type validation on the inputs to the application? Check the code…

As you can see, this strategy is painful, increases the complexity of the overall system, and makes security a hard problem. The truth is, the proxy model for web services, SOA and XML processing has been around now for about 10 years and its value has increased as companies have multiplied the complexity of their applications. The basic idea is to centralize generic policy enforcement in a single place, for both threat protection and trust enablement. The model works beautifully – developers write pure services, devoid of any security logic, and a single policy is pushed to the gateway where it can be easily maintained, monitored, audited and changed using configuration, not coding. This means that in practice, there is a trust relation between each of the services and the gateway and the one-time effort on the back-end applications or services is to go through the code once and remove security checks. Your developers can be free again to focus on business logic and the security architect can focus their attention on the gateway itself.

Here is a picture of the conceptual architecture:

Here we have the gateway acting as a policy enforcement point. The key idea here is that all security processing can be centralized. Threats are stopped at the edge, trust is maintained through a combination of message level security (encryption and digital signatures), session security (such as SSL), and authentication, authorization and auditing, which is done by calling out to existing identity management investments, such as CA Siteminder, Oracle Access Manager, IBM Tivoli Access Manager, LDAP, Active Directory, ADFSv2 and others. Once a trust relationship is established between the service endpoints and the gateway, the services themselves can be as pure as possible - devoid of security processing other than identity context, which can be provided by the gateway. Developers can finally be free of having to worry about security.

For those of us who have been in this space for awhile, this picture may elicit an obvious "so what" response, but I think it is a very powerful model for security. In fact, enterprises can approach this model without an actual gateway if they can manage to centralize security processing for a class of services. The real beauty of a model like this is that it specifically requires the simplification of coded-in security. How many other security models can make this claim?

It looks like Microsoft has released their long-awaited Active Directory Federation Services v2.0 ('ADFS v2.0') component for Active Directory.

Simultaneously with this release, Microsoft is pushing the concept of "claims based identity" as the new thought "superstructure" that according to Microsoft, is a seminal event in the history of thought for identity management.

Here is my favorite quote from Microsoft's book "A Guide to Claims-based identity management".

"The claims-based model embraces and subsumes the capabilities
of all the systems that have existed to date, but it also allows
many new things to be accomplished."

I must say this is quite a claim.

Let's step back and take a look at what ADFSv2 is actually doing on the wire, which is where the truth ultimately lies.

The model proposed by Microsoft equivalent to the assertion model of identity. In all cases, whether it is a web service, web site or SaaS application, the user authenticates himself or herself to ADFSv2 for a specific application and then receives a SAML assertion for that specific application which they then take to the target application in a browser or "smart client" (web service).

Microsoft is trying to elevate it's technology to greater philosophical importance by using the word "claim" in place of "attribute" or "role" or "property" of a user. This makes for some good marketing, but the SAML assertion that comes from ADFSv2 will have very specific attributes in it targeted for very specific target application. This is an important point because it means you can't simply take the SAML assertion and "federate it" anywhere as it will have "claims" (e.g. attributes) designed for a specific application, some of which might be quite sensitive.

For instance, a claim for an expense reporting application might have an employee's cost center as an attribute in the SAML assertion. This is great for federating the assertion to the expense reporting application, but not so great when federating the assertion to other applications, such as a partner website.

I looked around for a sample SAML assertion generated by ADFSv2 with some sample claims to dig in to the details, but they are hard to come by. I wonder why...

Notwithstanding my criticism, the model is a good one because moves the authentication and authorization logic further away from applications and into a centralized, trusted assertion. This is a step in the right direction and follows the trend of security decoupling that has proven to be useful for other technologies such as SSL and web services security in the past.

To conclude this post, I am leaving two unanswered thought provoking questions:

#1: What is the difference between a claim and an attribute? (Credit for the seed of this idea goes to Dr. Babak Sadighi of Axiomatics during a conversation we had at the recent Kuppinger show)

#2: Is there a need for "claims filtering/protection" - e.g. on-the-wire gateway functionality that can obfuscate, encrypt or delete sensitive claims in ADFSv2 issued SAML assertions when these assertions leave the Enterprise perimeter?

A colleague forwarded me this link from Lustratus Research. Incredibly, the analyst makes the following claim:

"I say “appliances” in inverted commas because Intel’s product is wonderfully described as a software “appliance”. Surely the award for the most spin in a product category goes to Intel."

I was a bit taken aback by this. I hope the analyst was being provocative on purpose. I wrote the following reply (which was subsequently deleted), as a clarification:

"Hello There – It seems that this is a very provocative report, especially with respect to the statements made regarding the Intel product.
First, off I have to say that I am from Intel, so as you must, please take my comment with a grain of salt.

I hope, however, that the analyst does not confuse and equivocate a nuanced product available in multiple form factors for different usage models with “marketing spin.” The facts speak differently in this case.

In fact, the Intel(R) SOA Expressway product (like some of its competitors) is available in three form factors (hardware, software and virtual image) – each of which can be properly called an appliance.

“Appliance” here does not necessarily reflect a strict category of hardware only, but instead set of management and monitoring capabilities such as a real-time dashboard, self-healing capabilities, alarms, alerts, management clustering, and high availability with a familiar web-based interface and easy management.

It is these capabilities that primarily characterize a software appliance. In this case we can think of a hardware appliance and then subtract out the physical security features. It is only natural that we can take this same form factor and package it for a virtual machine and we will arrive a similar form factor designed for a virtual private cloud. Incidentally, this is something especially difficult for a product only available as a pure hardware appliance.

Finally, because the Intel product relies primarily on a software layer that performs machine language processing of XML, the addition of hardware adds only physical security prowess, and is not a necessary form factor for a high performance deployment. All in all, the product is truly available in all three form factors – no spin required. Perhaps some of these facts can “spin” the customer closer to the truth about this particular product.

Blake Dournaee"

Is truth denied? I just wanted to make sure that our customers know that our appliance form factors (software, hardware and vm) are not elements of spin!

Blake