I'm speaking on a Panel on SOA Security at the SOA Executive Forum in New York City next week.
Jon Udell has listed some talking points for the discussion. Based on those talking points, here are my notes for the discussion:
On the role of security in SOA and ESB architectures:
Vordel allows security services to be part of the “fabric” of services that are on tap as part of an ESB. This work has involved drawing on some of the standards which are in place for security services. In particular, there is the OASIS DSS (draft) specification for signing and signature validation, and there is WS-Trust for translating between security tokens (as a “Trust Proxy”). These are very useful. But, there is no standard “security service” for XML encryption (i.e. to send a document to a service and say “encrypt this please”), analogous to how DSS provides the “SignRequest” SOAP interface to say “sign this please”. And there is no standard service for virus scanning (although we have built a connector to support this).
Even despite the relative lack of standards, I do think that security services should be part of an ESB. Here is a diagram from the CBDI analyst firm (from April 2005) which shows security services being part of an ESB.
I agree with this diagram in that it shows “security services” as being part of an ESB, along with orchestration (BPEL), transformation (XSLT), management (WSDM), and transport (i.e. mediation between different transports, guaranteed delivery, queuing).
Taking the example of a signing service, it means that developers do not have to worry about key storage, since keys can be stored at the “security server” that is exposing a signing service. However, access to the signing service must be authenticated, but that can use username/passwords instead of keys. So, I think that works well.
We’ve built our VordelDirector product to provide these “security services”. It is designed for architects deploying ESBs and SOAs. It enforces management rules across an entire SOA or ESB (the management it provides includes not only access management, but also performance management and lifecycle management).
Network security personnel still think in terms of perimeter security infrastructure. Which leads onto Jon Udell's second point, the “Role of gateways and appliances”:
The category of “XML Gateway” has really “stuck” in the market. People sometimes also use the term “XML Firewall”, but I like to use that term just for the “firewall-like” aspects of an XML Gateway (filtering based on the target, which is identified by URL and SOAP header rather than by port, as in the case of a network firewall, and looking for “malicious XML” such as the “XML bomb” attack discovered by Amit Klein at KaVaDo). In our customers, the primarily role of an XML Gateway hasn’t always been XML filtering (although that is important), it’s been for access control. i.e. allowing only trusted entities to access XML applications, to keep an audit trail of what is being accessed, and to link this in with enterprise ID management. This has a lot to do with the “identity of things” (i.e. it isn’t human beings who access Web Services, but you still need to control the access based on the “identity” of the application accessing the Web Service). Our integration with ID management from Entrust and Tivoli and RSA allows identity to span people (for accessing Websites) and applications (for accessing Web Services). I think that the "identity of things" is a powerful idea whose time is coming.
The role of appliances:
Our VS3000 XML Gateway appliance is an appliance for two reasons: (1) ease of deployment, and (2) speed (we use a crypto accelerator and a custom hardware XML accelerator too). But, you can’t do everything with an appliance because you have the “last mile” issue when connecting to a Web Service. That’s why we also provide the VordelDirector product which has plug-in agents for various Web Services platforms (and Web servers too). That distributed approach allows us to gather metrics on the operational health of XML application across the network. We find that a network ops person gravitates towards appliances, whereas an architect gravitates towards a more distributed “Web Services Management” solution. So, we provide both, and allow you to deploy both together.
Finally, on “Sub-document security”:
XML Signature and XML Encryption allow for "sub-document security", in which just part of a document can be signed or encrypted. However, signing and encryption still requires the usage of keys, and leads to a can of worms if many applications are all using locally-held keys. This points back to enterprise security services for encryption and decryption. Otherwise you have keys all over the network, which isn’t feasible.
11:36:13 AM 
|
