Security for SOA and Web Services

 Security Standards and Technologies

Is a web services security layer really required? To answer this question, one needs to look into the security concerns and try to address them using existing security technologies. The industry has a set of existing and widely accepted transport-layer security mechanisms, such as SSL (Secure Sockets Layer), TLS (Transport Layer Security). Despite their popularity, SSL and TLS (which is a minor update of SSL) have some limitations when it comes to web services.
 SSL is designed to provide point-to-point security, which is not enough for web services because end-to-end security is required. In a typical web services environment where XML-based business documents are routed through multiple intermediaries, it becomes difficult for those intermediaries to participate in security operations in an integrated fashion.
 SSL-based communication provides security (confidentiality, integrity) at the transport level rather than at the message level. As a result, messages are protected only while in transit on the wire. For example, sensitive data received on SSL channel, once persisted, is not generally protected unless one applies some encryption technology.
 Finally, SSL does not provide element-wise signing and encryption. For example, if there is a large purchase order XML document, and there is a need to sign or encrypt only a credit card element, signing or encrypting only that element with SSL is not possible.
All of these limitations make SSL and TLS unsuitable for most of the security needs of web services. In the last couple of years, this gap has been identified by the industry and considerable effort has been invested to provide a new security architecture to address the needs of SOA. It is important to realize that the new service oriented security architecture must adhere to the essential characteristics of SOA.
Organizations have existing security infrastructures in place, which protect the resources on diverse platforms. The fundamental goal of SOA is to enable the existing infrastructures to interoperate. The solution is to enable a security spanning layer over existing security infrastructures with a SOA.
SOA enables organizations to build a set of reusable security services that can be used by business applications. The resulting reusability ensures consistent security policies across platform with reduced development costs. For example, an authentication function can be offered as service. Due to the distributed nature of SOA, it is important that the standards-based architecture is adopted, which delivers interoperability and lets the infrastructure operate across organizational boundaries. In the last couple of years, much work has been done to create security standards, which are very promising.

Message Security

Message security is about providing message confidentiality, integrity, non-repudiation, and exchanging security credentials between web service client and web service.
WS-Security is an OASIS standard. WS-Security describes enhancements to SOAP messaging to provide message integrity, message confidentiality, and message authentication. WS-Security uses XML Signature to provide message integrity and message authentication and uses XML Encryption to provide confidentiality. WS-Security also provides a general-purpose mechanism for associating security tokens with messages. Examples of security tokens are X.509 certificate, SAML assertion.
XML Encryption is a W3C recommendation. It ensures confidentiality of XML information transfers. XML Encryption allows the parts of an XML document to be encrypted while leaving other parts open. WS-Security provides processing rules for using XML Signature for SOAP messages. JSR 106 (XML Digital Encryption APIs) defines a standard set of APIs for XML digital encryption services.
XML Signature is a W3C recommendation. It ensures message integrity and authentication. WS-Security provides processing rules for using XML Signature for SOAP messages. Signature can be applied over parts of an XML document. JSR 105 (XML Digital Signature APIs) defines a standard set of high-level implementation-independent APIs for XML digital signature services.
As mentioned above, in B2B applications, sometimes there is a need for message non-repudiation. Non-repudiation is required due to malicious senders who can later disavow having created and sent a particular message. Resolving non-repudiation issue requires message authentication and sender authentication simultaneously. This can be achieved by using XML Signature for message authentication and SSL-based sender authentication.