Editing WS-Security

{{Short description|Extension of SOAP}}
{{More citations needed|date=July 2024}}

{{Use dmy dates|date=January 2022}}
'''Web Services Security''' ('''WS-Security''', '''WSS''') is an extension to [[SOAP (protocol)|SOAP]] to apply security to [[Web service]]s. It is a member of the [[List of Web service specifications|Web service specifications]] and was published by [[OASIS (organization)|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 (protocol)|Kerberos]], and [[X.509]]. Its main focus is the use of [[XML Signature]] and [[XML Encryption]] to provide end-to-end security.

==Features==
WS-Security describes three main mechanisms:
* How to sign SOAP messages to assure integrity. Signed messages also provide [[non-repudiation]].
* How to encrypt SOAP messages to assure confidentiality.
* How to attach security tokens to ascertain the sender's identity.

The specification allows a variety of signature formats, encryption algorithms and multiple trust domains, and is open to various security token models, such as:
* X.509 certificates,
* Kerberos tickets,
* User ID/Password credentials,
* SAML Assertions, and
* custom-defined tokens.
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.

==Use cases==
===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.

===Non-repudiation===
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.

===Alternative transport bindings===
Although almost all SOAP services implement HTTP bindings, in theory other bindings such as [[Java Message Service|JMS]] or SMTP could be used; in this case end-to-end security would be required.

===Reverse proxy/common security token===
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.

==Issues==
* 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|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 [[Padding (cryptography)|CBC mode encryption/decryption]] is applied or if the CBC mode decryption is applied without verifying a secure checksum ([[Digital Signature|signature]] or [[Message authentication code|MAC]]) before decryption then the implementation is likely to be vulnerable to [[padding oracle attack]]s.<ref>{{cite web|last=Sabarnij|first=Sergej|title=Padding Oracle Attacks – breaking theoretical secure cryptosystems in the real world|url=http://www.nds.rub.de/media/nds/attachments/files/2011/08/padding_oracle_1.pdf|publisher=Ruhr Universität Bochum}}</ref>

==Performance==
WS-Security adds significant overhead to SOAP processing due to the increased size of the message on the wire, XML and cryptographic processing, requiring faster CPUs and more memory and bandwidth.

An evaluation in 2005<ref name="Lui">{{Cite web |url=http://grids.ucs.indiana.edu/ptliupages/publications/WSSPerf.pdf |title=Hongbin Liu, Shrideep Pallickara, Geoffrey Fox: Performance of Web Services Security |access-date=12 January 2010 |archive-date=24 February 2021 |archive-url=https://web.archive.org/web/20210224140108/http://grids.ucs.indiana.edu/ptliupages/publications/WSSPerf.pdf |url-status=dead }}</ref> measured 25 types of SOAP messages of different size and complexity processed by WSS4J with both WS-Security and WS-SecureConversation on a Pentium 4/2.8&nbsp;GHz CPU.
Some findings were:
* Encryption was faster than signing.
* Encryption and signing together were 2–7 times slower than signing alone and produced significantly bigger documents.
* Depending on the type of message, WS-SecureConversation either made no difference or reduced processing time by half in the best case.
* It took less than 10 milliseconds to sign or encrypt up to an array of 100 kilobytes, but it took about 100~200 to perform the security operations for SOAP.

Another benchmark in 2006<ref>[http://francoislascelles.sys-con.com/node/204424/ Francois Lascelles, Aaron Flint: WS Security Performance. Secure Conversation versus the X509 Profile]</ref> resulted in this comparison:
{| class="wikitable"
|-
! Security mechanism
! Messages/second
|-
| WS-Security (X.509) XML Signature & Encryption
| 352
|-
| WS-SecureConversation XML Signature & Encryption
| 798
|-
| Transport Layer Security
| 2918
|-
|}

==History==
Web services initially relied on the underlying transport security. In fact, most implementations still do{{Citation needed|date=January 2010}}. 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<ref name="Atkinson">[http://msdn.microsoft.com/en-us/library/ms951257 Bob Atkinson, et al.: Web Services Security (WS-Security)]. ''msdn.microsoft.com''</ref><ref name="Atkinson-alt">[http://schemas.xmlsoap.org/specs/ws-security/ws-security.htm Bob Atkinson, et al.: Web Services Security (WS-Security)]. ''schemas.xmlsoap.org''</ref> was published on 5 April 2002 and was followed up by an addendum<ref name="Della-Libera">[http://public.dhe.ibm.com/software/dw/specs/ws-secureadd/ws-secureadd.pdf Giovanni Della-Libera, Phillip Hallam-Baker Maryann Hondo: Web Services Security Addendum]</ref> on 18 August 2002.

In 2002, two proposals were submitted to the OASIS WSS Technical Committee:<ref name="wss-tc">[http://www.oasis-open.org/committees/wss/charter.php OASIS Web Services Security TC]</ref> 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",<ref name="draft13">[http://www.oasis-open.org/committees/download.php/2314/WSS-SOAPMessageSecurity-13-050103-merged.pdf Web Services Security: SOAP Message Security – Working Draft 13]</ref> 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<ref>[http://schemas.xmlsoap.org/ws/2002/07/secext schemas.xmlsoap.org]</ref> URL (and similar URLs of different versions).

The protocol is officially called WSS and developed via committee in Oasis-Open.

==Associated specifications==
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]].

==Alternative==
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|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 principle|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.

==See also==
*[[WS-Security based products and services]]
*[[Security Assertion Markup Language|SAML]]
*[[WS-I Basic Profile|WS-I Basic Security Profile]]
*[[X.509]]
*[[XACML]] – the standard for fine-grained dynamic authorization.

==References==
{{reflist}}

==External links==
*[https://www.oasis-open.org/standards#wssv1.1.1=OASIS Web Services Security 1.1.1] (Contains links to download specification documents.)
*[http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html WS-I Basic Security Profile]
*[http://www.cgisecurity.com/ws.html Web Services Security Documentation]
*[http://ws.apache.org/wss4j/ WSS4J] (WS-Security Java Implementation from Apache)
*[http://ws.apache.org/rampart/ Apache Rampart] (WS-Security Java Implementation from [[Apache Axis2]])
*[https://web.archive.org/web/20070711152141/https://wsit.dev.java.net/ WSIT] Web Services Interoperability Technologies (WSIT) that enable interoperability between the Java platform and Windows Communication Foundation (WCF)
*[http://www.pythontr.com/makale.py?tid=51 python ws-security example]

{{OASIS Standards}}

[[Category:Web service specifications|Security]]
[[Category:Computer security software]]
[[Category:XML-based standards]]