45. VuzbLApPnXiehowYuA==
46. </X509Certificate>
47. </X509Data>
48. </KeyInfo>
49. </Signature>
50. </wsse:Security>
51. </soapenv:Header>
52. <soapenv:Body>
53. application specific data/content
54. </soapenv:Body>
55. </soapenv:Envelope>:

Let’s look at the SOAP message in greater detail. As you can plainly see, this is a typical SOAP message with an outermost opening and closing <soapenv:Envelope> tag set. The SOAP envelope contains <soapenv:Header> and <soapenv:Body> sections. The WS-Security section, as defined by the WS-Security specification, is positioned within the SOAP Header and is designated by the opening and closing <wsse:Security> block, lines 3-51. The <Security> header block provides a mechanism for attaching security-related information targeted at a specific receiver (the SOAP actor). Since only one SOAP actor is involved in this use case, only one <Security> header block is contained in the message.

In line 3, the SOAP actor attribute defines the recipient of a header entry, Security soapenv:actor=”http://www.jStartcustomer.com/actors#verifier”. Line 3 also contains the soapenv:mustUnderstand=”1" attribute. By setting the SOAP mustUnderstand attribute to “1”, we indicate that the service provider must process the SOAP header entry. As per the SOAP specification, since the attribute is set to “1”, if the receiver cannot obey the semantics (as conveyed by the fully qualified name of the element) and process the message according to those semantics, the receiver MUST fail processing the message and generate a fault.

SignedInfo and Digests

Lines 4-14, <SignedInfo> </SignedInfo>, describes the signed content of the message. Note that as is customary with digital signature applications, a digest is used to facilitate faster processing. This is a standard industry practice and is done for performance reasons. The payload (the SOAP Body) of our SOAP message is quite long, and the process of applying a public key algorithm to the full message could significantly impact the performance of our Web service. As such, a digest is used. A digest is a fixed length, short message whose digital signature can be quickly generated and verified. When the message is received, our Web service digital signature verifier class (implemented as an Apache Axis plugable provider) will compute the digest and verify that the newly-computed digest matches the digest that was sent.