Web Services Architecture and Its Specifications [Electronic resources] : Essentials for Understanding WS-* نسخه متنی

Message Integrity and Confidentiality

Message-level security is the key building block for end-to-end security. When using message-level security, no transport-level security is required. Requirements for message-level security are message integrity, message authentication, and confidentiality. Message integrity ensures that a message cannot be changed without detection. Use of XML Signature [XMLSIG] ensures that message modifications can be detected.

Message authentication identifies the principal that sent the message. If public key encryption is used, the unique identity of the principal can be determined. The use of public key encryption with keys certified by a trusted source provides this authentication. However, if symmetric key encryption is used, this is not the caseonly the group of principals that know the shared secret can be identified.

Message confidentiality ensures that a message cannot be read by an unauthorized third party during transmission. SOAP messages are kept confidential through the use of XML Encryption [XMLENC] in conjunction with security tokens.

Mechanisms for integrity, authentication, and confidentiality take the original message (or parts of the message) as input and produce appropriate data (such as a checksum) as output. For example, the signature of an XML element could, in a simple case, be implemented as the asymmetric encryption of a hash of all the characters of the XML element. This encrypted hash could then be stored and transmitted in the message.

XML documents can be thought of as strings of characters. The character-by-character comparison is critical in security operations such as XML signatures. A one-character difference is a different result. Serialization is the method used to represent objects "on the wire." For example, serialization is used to create the XML representation of a SOAP message. Any inessential typographical variations produced by different serialization software are ignored by message-processing software but significantly impact the security software. The Infoset representation of an XML message ameliorates this issue. For XML signatures to work, messages must be transformed to an XML form that is consistent for all parties. Canonicalization is the term used to describe the method used to produce a consistent view of the noncritical information, such as line breaks, tab spaces, ordering of attributes, and the style of closing tags. Signatures include the canonicalization method used to enable the recipient of a message to process the security information in a manner consistent with the sender. The specific canonicalization method in use by a service is a useful policy assertion to place at a WSDL portType binding or a WSDL Port.

WS-Security specifies mechanisms to include security tokens as part of a message for message integrity confidentiality and single message authentication. For message integrity, the specification details how a cryptographic signature is represented and associated with specific parts of the SOAP message. The approach allows arbitrary well-formed fragments of the message to have separate signatures. In a similar manner, confidentiality is achieved through the encryption of well-formed fragments of the message. Authentication is achieved using digital signatures.

WS-Security also specifies mechanisms for referencing relevant XML entities. Identity references are used to select message elements, such as signatures, or to correlate signatures to security tokens. This also allows security tokens to be referenced. For efficient security reference processing by SOAP intermediaries, elements that must be referenced use an identity attribute.

The WS-Security specification describes common security mechanisms in use today but does not preclude new ones from being added in the future. Because the SOAP processing model uses the header elements to make processing decisions, great care must be exercised when deciding which elements in a SOAP message to encrypt.

When deciding which elements are to be encrypted and which encryption algorithms to use, Web service designers must be aware of how the message will be processed. These decisions are even more important when specific header elements need to be processed by third parties or intermediaries. If those parties are not privy to the appropriate decryption data or to the conventions used in encrypting the XML elements, they will not be able to operate correctly. In addition, each processing node must have a common understanding of the security information included in the message.

One natural choice for encrypting an XML element in a header is to encrypt it completely, substituting the original element for one that is of type encrypted data. Drawbacks to this straightforward approach exist. Intermediaries, for example, have a hard time determining which elements must be processed (those adorned with the mustUnderstand="1" attribute). Also, because the element type is changed, determining its original type is difficult.

An alternative approach is to transform the element to one where all the key attributes needed for correct SOAP processing are preserved and the original element is encrypted and placed in a distinguished subelement. The advantage of this approach is that correct processing can be achieved even by intermediaries that do not know how to decrypt the element. A drawback to this approach is that it requires that the convention used to represent the original element be understood by all parties. While WS-Security does not currently provide guidance on this approach, we expect future work to do so. The alternate method is preferred because it enables the correct processing of all SOAP header elements.

Several kinds of security tokens are described in WS-Security's profile specifications. Profiles have been developed for tokens representing user names, X.509 certificates, and XML-based security tokens. XML-based security tokens include the Security Assertion Markup Language (SAML) [SAML] and the eXtensible rights Markup Language/Rights Expression Language (REL) [REL]. Specifications for the use of Kerberos tickets are also under development.