Three Security Approaches for SOA
SOA brings changes in the requirements for data confidentiality and data integrity. When a message sent to party 1 (brokerage) contains parts intended for party 2 (bank), we need the ability to differently encrypt and/or sign the part that is intended for use only by party 2. Clearly, traditional transport layer security mechanisms such as SSL/TLS are not good enough here, as they cannot stop party 1 from reading and/or tampering with the message part intended for party 2.
Message-level security (as opposed to transport-level security) is a new approach to solve this problem. With this approach, different parts of a message can be protected differently, to make them usable only by intended parties in the message path.
Security as a service
A security service can offer applications the ability to authenticate, authorize, encrypt/decrypt messages, sign messages/verify signatures, and log messages. It may also scrub messages to protect applications against known and unknown vulnerabilities. Applications might still need to know a little bit about security—for example, they may need to know how to invoke a security service and use the information provided by the security service in return—but the meat of the security logic can be executed by a central security service.
The idea behind policy-driven security is simple. Security requirements and mechanisms must not be hard-wired into applications. Instead, security requirements of an enterprise should be declared separately as a “security policy.” A security policy declaration becomes handy in many ways: It separates security logic from business logic, leaving the former to security specialists. It becomes easier to ensure consistency of security enforcement across multiple applications.
SOA security 2008, Ramarao Kanneganti, Prasad Chodavarapu