#7 Not Planning for Web Services Security Organizations tend to start small when first building SOA with Web services. The extent to which Web services technology grows within a given environment is typically related to the comfort level developers and architects have with the overall technology framework. Once services begin to take on greater amounts of processing responsibility, the need for message-level security measures as well as security controls that apply to shared services begin to arise. The WS-Security framework establishes an accepted security model supported by a family of specifications that end up infiltrating service-oriented application and enterprise architectures on many levels.
Hmmm...infiltrating...I like that. Let me infilitrate your car with airbags and ABS.
Even if your vendor platform does not yet provide adequate support for WS-Security, and even if your current SSL-based implementation is meeting immediate requirements, it is advisable to pay close attention to the changes that are ahead. Proceeding without taking WS-Security (and its emerging extensions) into account will inevitably lead to expensive retrofitting and redevelopment. This impact will be amplified when organizations begin to grow their service inventory and decide to only then apply the appropriate security
So if I turn this "Not Planning for Web Services Security" around can I say we should Build Security In to our Web Services? It is hard to retrofit security, and not that hard to build it in in the first place. You don't have to go back and restest and redeploy all your transactions for example. WS-Security (and SAML) is a good place to start, then move on to WS-Trust, XACML, et. al. It is still surprising when you talk to vendors, like ESB vendors, who should be in prime position to take advantage of WS-Trust yet they really don't even have it on their roadmap yet, in some cases.
Security is part of the friction that comes with integration. As mentioned in Only Sustainable Edge, the real trick in integration is making sure that the friction is productive friction and not dysfunctional friction, Web Services security standards give a clear path to that, because they deliver interoperable message level security which the industry has heretofore lacked. So systems may emerge from a Web Services integration with security domains that can compose together instead of representing abritrary boundaries because of technical constraints.