| In general the WS-Security standard does not define any new security mechanisms; it just provides a standard way of packaging existing mechanisms into a SOAP message. Message time stamps are the exception to this in that WS-Security defines a specific structure for including a message time stamp in the security header. From a security perspective, you often need to know information about the freshness of a message. If a message is stale , depending on the context, it should possibly be ignored. WS-Security defines a mechanism, using the Timestamp header for the message's sender to add information such as when the message was created and when the message should expire. Listing 7.22 shows an example of a Timestamp header (note that the wsu prefix refers to the WS-Services Utility namespace). Listing 7.22. An Example of a <Timestamp> Header <S:Envelope> <S:Header> <wsu:Timestamp> <wsu:Created>2001-04-03T08:42:00Z</wsu:Created> <wsu:Expires>2001-04-04T09:00:00Z</wsu:Expires> </wsu:Timestamp> ... </S:Header> <S:Body> ... </S:Body> </S:Envelope>
As you can see here, the message's sender has declared a Created time and an Expires time. You need to take into account that the Expires time was the time on the machine that sent the message; consequently, potential clock skew ”a difference between the sender's clock and the receiver's clock ”can exist. Message time stamps are a useful addition to the security header and can be used for other purposes than just finding the time; for example, a TimeStampTrace element can be used as a target of an intermediary's signature to prove the claim of an X.509 certificate. WS-Security and Web Services Performance Just like SSL, WS-Security poses a performance penalty: in transmission time, memory, and CPU. |
Message Size As you may have noticed from the examples in this chapter, a message that has been secured with a WS-Security header can have a significant amount of security information embedded within it. In one of the examples with a message 39 lines long, the security header was 27 lines and the message body was only 5 lines! This example did not contain X.509 certificates or SAML assertions, which would have ballooned the size of the header even more. In high-volume situations, size could significantly affect transmission time, processing time, and memory consumption. |
Message Processing Although WS-Security itself can be implemented in a streaming fashion, giving some improvement to the WS-Security processing itself, in general, WS-Security Signature and Encryption will hurt streaming Web services implementations . This stands to reason because the entire message must be read to create or validate the XML Signature(s) and to encrypt or decrypt through XML Encryption. This particularly hurts for large inbound messages because the optimizations of Web services engines for streaming are lost. |
CPU Utilization In general, security technologies such as digital signature and encryption are computationally intense . Shared key technology, used for bulk encryption, tends to be fast; however, public key technology tends to be slow. So, digital signature creation and validation, as well as shared key wrapping, could add significantly to the processing burden . Also, we have heard anecdotally that the XML Canonicalization process, similar to other XML processing operations, can be slow. Although the significance of this will vary with the WS-Security and Web services engine you use, overall, you will likely find that WS-Security can significantly degrade your performance, particularly in high-volume or large-message-size situations. The solution will probably be hardware accelerator devices that operate at or close to wire speed and that have specialized cryptographic hardware chips for fast encryption, decryption, and even hashing functions. |
|
