Randy Hefner wrote an encouraging piece recently in ComputerWorld titled SOA Security: Good Enough and Getting Better. I say encouraging because from his perspective—which is broad and well-informed by virtue of his role as a Forrester analyst—most organizations now understand the importance of SOA security, and they are implementing the basics today. The more advanced pieces, particularly around complex identity-centric use cases such as single sign-on and federation, remain elusive; but at least there is a solid baseline to work from. Randy maintains:
“Thus it is important, even if you start with a simple SOA security solution, to anticipate the need for and leave paths open to build additional, deeper security functionality as business requirements demand and SOA security maturity allows.”
This is something I definitely agree with. Security can begin with the basics, as long as you put the time and energy into your basic policy and security architecture upfront. If you design it for growth, you can easily add in support for scenarios like non-repudiation later on. Security should always be an iterative process. It’s something you never finish, and you need to keep this in mind as you are designing your security architecture. You don’t want your tools and infrastructure to let you down at some point in the future.
But Randy’s real gem is here:
“Forrester strongly recommends that you design a solution that does not require application developers to do security-related coding. Even with strong guidelines and code reviews, embedding security into application code is risky both in terms of achieving consistent security and of allowing future flexibility and enhancement of application security.”
Bravo Randy—and Forrester by extension. This is the critical insight that so many people miss. Here at Layer 7, we’ve been evangelizing for years that developers need to be taken out of the equation when it comes to securing the communications that make up a secure SOA application. SOA security is a complex discipline, and it’s risky to assume that each of your development teams will implement it consistently and correctly. You need to dedicate an expert to the problem and make this person (or persons) responsible for implementing a security model across all of your SOA apps.
The fundamental associated risk with standards like WS-Security (WS-S) is their complexity. This is a very broad specification, one that relies on a host of other specifications as its core. By design, it is not prescriptive about how you should use it; rather, it is a framework for securing SOAP transactions to your business needs.
I was (am still am) an editor of the WS-I Basic Security Profile (BSP), along with colleagues from IBM, from Nortel, and from Microsoft (a number of other companies also contributed to the specification as participants in the working group). I’ve worked alongside the best SOA security minds on the planet, and I learned first hand how easy it is to inadvertently create WS-S (or, for that matter, BSP)-compliant security models that are riddled with holes. OASIS and WS-I, through the standards and profiles they produce, do not have a mandate to offer formulas for securing SOA apps. They are in the business of providing frameworks for experts to implement secure solutions, or to promote interoperability.
This is why it’s so important that security for SOA be placed in the hands of dedicated experts, and that the tools to support an overall governance strategy—such as Layer 7 SecureSpan Gateway line—allow security policies to be enacted simply and comprehensively. I’ve always said that the soul of good security is consistency. Your tools need to support this.
In a forthcoming blog entry, I’ll demonstrate how simple it is to implement SOA security using Layer 7’s SecureSpan Gateways, and thus deliver on Randy’s assertion that we must take application developers out of the SOA security process.
SecureSpan Gateway Cluster deployed in a common, edge-of-the-network scenario. This is just one example of many different deployment possibilities. Here, the gateway cluster provides consistent security policy enforcement for all services published by the organization.
K. Scott Morrison's Blog 