I’ve been looking at how people have been implementing input validation and entitlement evaluation within service-oriented architectures (SOA). One of the nice properties of an SOA is service composition, so transformation and validation can be implemented as an independent utility service and then composed with other services. But service composition has the drawback that one must remember to compose, so in some implementations input validation is implemented through an interception mechanism rather than through composition.

Another example of this interception technique is visible in some XACML implementations. In XACML, the Policy Enforcement Point (PEP) is decoupled from the application logic. Several of the implementations of PEP’s I’ve looked at use some form of interception in front of the web service to hook the service invocation. The PEP can then extract the information it needs to perform the entitlements check.

This interception technique raised the question amongst one of my colleagues as to whether using such a scheme represented “bolt-on” security or “built-in” security. I believe that the concern is that, when used for input validation, the interception mechanism allows the validation to be done outside of service. In fact, the validation can be developed even after the service has been deployed.

I argue that this mechanism is “built-in” and not “bolt-on” security. I believe that this technique merely represents an extension of the aspect-oriented programming (AOP) concept of a cross-cutting concern within the context of a service-oriented architecture. It’s like “aspect-oriented service architecture.” Having aspects within a service-based architecture is good for all of the same reasons that aspects are good within a programming framework.

Now, I’m not suggesting that all uses of interception can be classified as “built-in.” I think that for such security aspects to be considered “built-in” that there must be some level of binding between it and the action. For example, for input validation to be considered “built-in,” the validation aspect must be able to have access to all of the input data values and must perform specific validations based on the semantics of the service being invoked. It’s not sufficient to have some lame black-list filter that looks for “<” and claim that this is “built-in” security. No, the input validation aspect must know about the data types and semantics of all the data coming into the service and have specific validation for each datum.

Maybe I’m over generalizing the notion of cross-cutting concern in service architectures. Maybe these two aspects (and they are conceptually closely related) are the only two aspects that can be factored out of the application logic so cleanly. But, just because they can be factored out and implemented independently from the application logic, I don’t think that the factoring justifies it being called “bolted on.”

Technorati Tags: soa, software security

I am strong advocate of service oriented architectures. I have seen them work—not in theory, not in demonstration, but in real, deployed, mission critical applications. In sitting down to write this blog entry I was going to do yet another “SOA - Hype vs. Reality” essay. I’ve written a lot of these over the past four or five years, and, frankly, theses pieces are getting boring to write and boring to read. Its just not a burning issue — the next generation architecture debate is over, and SOA won.

Sure, most of what you see when you walk into a big IT shop is still monolithic applications, but those are echoes of IT history—dead men walking. SOA won because it is a natural evolution and logical extension of the way we have been building systems since Grace Hopper showed us the light. Our first programs looked monolithic, but only on the surface. We learned that good practice requires us to decompose our programs into procedures, subroutines, (or whatnot depending on the language) that had limited functionality with well-defined interfaces—nothing too large to fit in the space between our ears. Code reuse as the Holy Grail.

SOA is just the extension of good programming practice except that high bandwidth, reliable, standards-based networks and emergent standards for things like message transport, service registration and service invocation mean that our systems need not operate in a single memory space. The acronym SOA may not survive. Software sales dudes always come up with new names to sell a polished up version of the same-old, same-old, but service-oriented architecture and, more importantly, service-oriented architecting is here to stay; its centrality in future systems is as inevitable as the sun rising in the east.

With that rant out of the way, what I want to say here is that there are unique security issues related to security. I plan to discuss these in forthcoming blog entries, but I have a meeting today with the Ettienne Reinecke, CTO of Dimension Data, one of the best networking companies in the business. I have been thinking hard about how the guys like him play in SOA beyond giving us reliable pipes. Let me share my thoughts.

Networks work really well—software not so well. Why? I suggest that the success of the networks lies in three factors—componentization, standardization and that management. Networks are not monolithic. They are composed of lots of individual pieces, each with a well-defined function (sound like SOA?). The performance and interfaces of each component type are very well-defined by standards. This means that different components can be integrated with moderate ease and some reasonable expectation that they will work together. It also means that the people who develop the components can continue to refine their designs—to polish them until they are sparkle, making each generation, faster, better and cheaper—as long as they keep the interface constant.

Finally, the network guys assume that the network isn’t going to work. They assume that components will break, so they instrument the network to monitor its performance and they watch it carefully. Good network engineers also design for graceful degradation—the ability to lose performance in increments rather than catastrophically (think escalators vs. elevators). We on the software side can learn from this. The presumption of fallibility and the capacity for graceful degradation are alien concepts in the software world. They shouldn’t be.

In moving to SOA, we are componentizing. In adopting web-service standards we are standardizing, though our standards are much less mature than those for networks. Good for us—we have to two of the lessons down—componentization and standardization.

Let’s take the final step, and build our SOAs with the assumption that they will fail (a safe assumption) and engineer-in monitoring and the capacity for graceful degradation from the beginning. We can “ping” network components to see if they are alive, query their state, test them and change their state during operation. We should be doing this for SOA services. Ultimately, system operators should be able to look at panels like those now used for network operations, showing in color codes the status of each service. They should be able to detect problems and fix them on the fly.

Essentially, as we move towards SOA we are shifting from thinking of our systems as discrete entities to thinking of a computing ecosystem that runs 24 hours a day, 365.2564 days per year (more or less). This model is completely unnecessary for a simple program that does one thing, and only runs once in a while, but these are becoming an endangered species.

The trend in IT has always been towards greater integration. The data from one program feeds into the next, and the next…and the next. We can think of a data store as the DMZ between two applications or we can think of it as a cache in a larger system. The boundaries between systems are often arbitrary and are often simple reflections of org-chart boundaries rather than computational or business logic. At the level of the enterprise, we are evolving towards a more comprehensive view, beginning with simple shared services like database and directory, but moving, inexorably and inevitably towards shared functionality.

The network engineers have already made this transition. We should lean from them and relentlessly componentize, standardize and manage.

Technorati Tags: software security