Web Services Security (WS-Security, WSS) is an extension to 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), , and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.
WS-Security describes three main mechanisms:
The specification allows a variety of signature formats, encryption algorithms and multiple trust domains, and is open to various security token models, such as:
The token formats and semantics are defined in the associated profile documents.
WS-Security incorporates security features in the header of a SOAP message, working in the application layer.
These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and security technologies. In general, WSS by itself does not provide any guarantee of security. When implementing and using the framework and syntax, it is up to the implementor to ensure that the result is not vulnerable.
Key management, trust bootstrapping, federation and agreement on the technical details (ciphers, formats, algorithms) is outside the scope of WS-Security.
If a SOAP intermediary is required, and the intermediary is not more or is 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.