<wslic:binaryLicense wslic:valueType="wslic:x509v3" xsi:type="xsd:base64Binary"> MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...RnSNBe8DQve qD6a3gUACyZ6XVe3u </wslic:binaryLicense> </wssec:credentials> </S:Header> ... <!-- Body here--> ... </Envelope> As you see, the message contains a credentials element (as defined by the WS-Security specification). This element has a child element of binaryLicense (as defined by the WSLicense specification), which contains the X.509 certificate. If you want to pass an alternative form of license or alternative credentials, you can replace binaryLicense with the appropriate option from those previously listed.
Message Integrity In Chapter 10, you learned that you must have control of both the client and the Web service in order to ensure the integrity of data, and that no current SOAP standard provides for integrity. This situation will change because the integrity mechanism of the WS-Security specification provides privacy through the use of signatures that are compliant with the XMLSignature specification. You insert these signatures into an integrity SOAP header. Signatures provide two benefits: integrity (the message has not been altered in transit) and nonrepudiation (you must have sent it because you signed it). The specification allows you to include one signature for an entire message or multiple signatures, each relating to a different portion of the message. For example, this is particularly useful when a message is forwarded from one department to another and each department adds to the message; the signatures can provide a history of integrity for the document. Another important issue that the specification addresses is that of SOAP headers, which are volatile and often in flux. For example, the WS-Routing specification (more on this a little later) allows SOAP headers to change legitimately; thus, a message receiver might not be able to verify a signature based on the entire SOAP envelope, including these headers, even though the message body has not changed. The use of multiple signatures can negate these effects, but the specification recommends the use of a Routing Signature transform. A Routing Signature transform bases its signature digest computation on the SOAP envelope but excludes the WS-Routing headers, which are liable to change legitimately. A message recipient can thus verify the signature even though some of the WS-Routing SOAP headers might have changed. In addition to the Routing Signature transform, the specification supports all the algorithms and transforms defined by the XML-Signature specification. The following example shows a SOAP message that contains a single XML-Signature. The integrity node set, which contains all the signature information, is shown in bold. <?xml version="1.0" encoding="utf-8"?>
<S:Envelope xmlns:S=http://schemas.xmlsoap.org/soap/envelope/
364