Validation. Security headers, SAML, WS-Security, etc are useless unless they’re being validated against SOMETHING. Usually this something is an LDAP, and in a Microsoft environment the Active Directory. If you’ve got a security device such as a Datapower, it can be configured to perform this validation. So can many SOA runtime governance and SOA security tools. Use it!
Exclusivity. Sources of requests must be validated. If there’s a Datapower (or similar) device in the picture, this means both providers and ESB’s only accept requests from the security device. If not, security agents have to be configured to validate sources. If no agents exist, there’s a hole to be exploited.
Protocol Independence. Security rules must remain true regardless of protocol…http, https, ftp, s/ftp, MQ, Tibco, etc. To act in this fashion, every message must contain the XML security header whether it’s sent by HTTP or another protocol such as FTP or MQ. Security is independent of protocol.
Audit Database. Sufficient transaction content, particularly the header, must be saved for auditing, problem research, and potential forensic research. This has to be done well, meaning an independent asynchronous process that causes no overhead to the services. A message queue with an independent logging process works very well to solve this. However it can generate a large quantity of data, so a good archiving and/or deletion policy has to be in place as well.
Attack Protection. Attack protection is an important feature that may not be necessary for internal services but is critical for internet facing services. It prevents various forms of XML and Injection attacks. However, it requires a security device such as the Datapower or Layer 7 XML boxes.