The Web Services Security specification defines mechanisms to protect messages designed for use with Web services. The Web Services Security Technical Committee of the Organization for the Advancement of Structured Information Standards developed the standard.
Web services applications communicate using Simple Object Access Protocol (SOAP) messages, which are defined in XML. These messages are most often transported over HTTP, but can, in principle, be carried over any underlying protocol. WSS provides a framework for encrypting, signing and authenticating SOAP messages.
WSS also defines XML elements that can be used to provide integrity (write) protection, confidentiality (read) protection and authentication. It does this by using other specifications, while adding some key elements of its own.
WSS implements digital signatures and encryption by referencing the XML digital signature and XML encryption recommendations developed at the World Wide Web Consortium.
Processing digital signatures of XML documents is complex because slightly different forms of the same document are considered to have the same meaning. For example, white space can be added or removed, and declarations can be moved or eliminated if they are redundant. Because these variations would produce spurious signature validation errors, it is necessary to define a standardized, or canonical, form for an XML document. The sender computes and signs the canonical form. The receiver also computes the canonical form to verify the signature.
Because Web services will be used in many environments, WSS makes it possible to use various systems to distribute keys and other authentication information in what it refers to as tokens. X.509 certificates and Kerberos tickets are carried in binary tokens, while SAML assertions and XrML licenses are XML tokens. WSS also defines a user-name token, which might be used in conjunction with a password.
The most important new element WSS defines is called Security and contains XML elements related to message protection. The Security element appears in the SOAP header, and there can be one for each node that will receive the message. The information in the Security element lets a sender tell a receiver what data has been signed and what has been encrypted, the order in which to perform the operations and what keys to use. WSS also lets senders specify the creation and/or expiration date/time of security information.
There also is a security token reference, which is used to point to tokens under various circumstances, such as when it is used more than once within a message.
WSS does not specify a particular set of message exchanges and cryptographic operations the way Kerberos or Secure Sockets Layer (SSL)/Transport Layer Security (TLS) do. It is expected that other specifications will describe detailed usage patterns and even add elements to implement and optimize complex capabilities. However, WSS can be used directly to meet simple needs, such as signing or encrypting portions of a single message.
WSS consists of a core specification and a profile for each token type. Work on the standard began in the fall of 2002.
In April, OASIS approved the WSS: SOAP Message Security 1.0 core specification and the WSS: Username Token Profile 1.0 and Web Services Security: X509 Token Profile 1.0. The WSS Technical Committee is working on SAML, Kerberos and XrML token profiles.
Alternative mechanisms, such as SSL/TLS, can be used to protect Web services messages. For many applications they might prove satisfactory, but they have more limitations than WSS. For example, WSS permits the signing and/or encryption of selected portions of a message. It is possible for a message to be signed at one node, additional data to be added and signed by a second node, and finally verified by the receiver. And an intermediate node can process portions of the message, even though other portions have been encrypted. As Web services become more complex, the need for WSS will increase.
Lockhart is a principal engineering technologist for BEA Systems and a member of several OASIS committees, including the WSS Technical Committee. He can be reached at hlockhar@bea.com.
