Безопасность веб-сервисов (WS-Security): принципы и реализация.

Web Services Security (WS Security, WSS) is an extension to SOAP to apply security to Web services. It is a member of the Web service specifications and was published by OASIS. The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as Security Assertion Markup Language (SAML), Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end to end security.

If a SOAP intermediary is required, and the intermediary is not more or less trusted, messages need to be signed and optionally encrypted. This might be the case of an application level proxy at a network perimeter that will terminate TCP (transmission control protocol) connections.

One method for non repudiation is to write transactions to an audit trail that is subject to specific security safeguards. Digital signatures, which WS Security supports, provide a more direct and verifiable non repudiation proof.

Although almost all SOAP services implement HTTP bindings, in theory other bindings such as JMS or SMTP could be used; in this case end to end security would be required.

Even if the web service relies upon transport layer security, it might be required for the service to know about the end user, if the service is relayed by a (HTTP ) reverse proxy. A WSS header could be used to convey the end user's token, vouched for by the reverse proxy.

If there are frequent message exchanges between service provider and consumer, the overhead of XML SIG and XML ENC are significant. If end to end security is required, a protocol like WS SecureConversation may reduce the overhead. If it's sufficient, use only encryption or signing, as the combination of both is significantly slower than the mere sum of the single operations. See Performance below. The merging of several XML schemata like SOAP, SAML, XML ENC, XML SIG might cause dependencies on different versions of library functions like canonicalization and parsing, which are difficult to manage in an application server. If only CBC mode encryption/decryption is applied or if the CBC mode decryption is applied without verifying a secure checksum (signature or MAC) before decryption then the implementation is likely to be vulnerable to padding oracle attacks.

Web services initially relied on the underlying transport security. In fact, most implementations still do. As SOAP allows for multiple transport bindings, such as HTTP and SMTP, a SOAP level security mechanism was needed. The lack of end to end security because of the dependence on transport security was another factor. The protocol was originally developed by IBM, Microsoft, and VeriSign. Their original specification was published on 5 April 2002 and was followed up by an addendum on 18 August 2002. In 2002, two proposals were submitted to the OASIS WSS Technical Committee: Web Service Security (WS Security) and Web Services Security Addendum. As a result, WS Security was published:
WS Security 1.0 was released on 19 April 2004. Version 1.1 was released on 17 February 2006. The version 1.0 standard published by OASIS contained a number of significant differences to the standard proposed by the IBM, Microsoft and VeriSign consortium. Many systems were developed using the proposed standard and the differences made them incompatible with systems developed to the OASIS standard. Some refer to the pre OASIS specification as the "WS Security Draft 13", or as the Web Services Security Core Specification. However these names are not widely known and indeed today it is hard to clearly identify whether an application or server is using a pre or post OASIS specification. Most forum posts use the keyword "WSSE" to refer to the pre OASIS version because it mandated the use of a "wsse" XML namespace prefix to the URL (and similar URLs of different versions). The protocol is officially called WSS and developed via committee in Oasis Open.

The following draft specifications are associated with WS Security: WS Federation, WS Privacy, WS Test. The following approved specifications are associated with WS Security: WS Policy, WS SecureConversation, WS Trust, ID WSF. The following architectures make use of WS Security: TAS3.

In point to point situations confidentiality and data integrity can also be enforced on Web services through the use of Transport Layer Security (TLS), for example, by sending messages over HTTPS. WS Security, however, addresses the wider problem of maintaining integrity and confidentiality of messages until after a message is sent from the originating node, providing so called end to end security. Applying TLS can significantly reduce the overhead involved by removing the need to encode keys and message signatures into XML before sending. A challenge in using TLS would be if messages needed to go through an application level proxy server, as it would need to be able to see the request for routing. In such an example, the server would see the request coming from the proxy, not the client; this could be worked around by having the proxy have a copy of the client's key and certificate, or by having a signing certificate trusted by the server, with which it could generate a key/certificate pair matching those of the client. However, as the proxy is not operating on the message, it does not ensure end to end security, but only ensures point to point security.