Truth in SOA

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?