From CSO interview with David Yeates, IT Head for EBS Building Society on why they use Vordel for Web services & XML Security services (emphasis added):
Dive deeper into how you reached the conclusion that the security architecture was needed.
Yeates: Service-oriented applications are fundamentally different from traditional monolithic applications. Web services are dynamic, they look up, discover and bind to each other at run time. This means that the internal network has also to be considered a dirty environment. A process-driven development creates dynamic applications where business processes can be easily created and changed. This presents major change management, service management and compliance challenges for an organization. Transactional security becomes very complex, very fast.
If you run a Java application you can rely on the java security model, if you run a J2EE application or .Net application you can rely on those application containers for security services. However, if you are doing Web services, then you have no container to rely on. You must use something else for security policy enforcement and security policy decision making, so the XML Gateway architecture really buys you two things. First, you get a measure of protection from the internal dirty environment, and second you get a place to enforce policies, which you otherwise lack.
One of the best architects I worked with made the case and bought a XML Gateway as a runtime API. Meaning a way to leverage the simplified APIs for SAML and WS-Security, so his developers didn't need to write them themselves. In other words the cost of the XML Gateway hardware was much less than the developers time to write it. Not to mention the opportunity cost, because it would need to be his best developers to write security standards wrappers. So he got the APIs at 50 cents on the dollar and got the accelerated hardware runtime for free.
By the way, the article discusses the XML Gateway in the context of an SOA security architecture, but the same thins apply to REST which is usually deployed without security.
Comments