Common Problems Composing Security with Streaming

Security and streaming are two features that often do not get along with each other. Although the concepts are not inherently in conflict, their implementations often do things that cause problems for the optimal execution of the other.

You may have seen that the message security channel, like the reliable messaging channel, in its native mode likes to buffer messages. This is because signing is one of the aspects of message security. The message signature is typically computed based on the contents of the message to allow detection of any changes. Although you could still achieve some benefit from streaming on the network and on the client, buffering of the message requires storage space on the server even though that storage space doesn't have to be in memory. Pre-computation of the message also negates one of the major benefits of streaming: the interleaving between computation and transmission of the data.

A stream security mechanism, such as SSL, is one way to avoid this buffering problem. Stream to stream transformations tend to be less likely to assume complete knowledge of the data than message to message transformations. One popular combination to use streaming with message security is to secure transmission of the messages with stream security and to use message security only for passing credentials.

HTTP authentication is another implementation that in some cases needs to buffer messages. HTTP defines a challenge and response for its basic authentication model. You might be able to predict the challenge and send the appropriate response as part of the request. If not, then the request needs to be transmitted from the beginning when the challenge response is supplied.

In most cases it would be difficult to completely regenerate the request. Instead, the transmitted portion of the request is buffered so that it can be transmitted again. It is unpredictable how much of the request needs to be buffered since the challenge is asynchronous with respect to the response. This leads to many implementations that either do not work with streaming or only work when the HTTP server behaves nicely. The server may read as little or as much of the request as it likes before deciding to initiate the challenge. In practice though, the server most likely would like to issue the challenge sooner rather than later so that it can stop processing the request.

Next time: Working with Session State

Comments

• Anonymous
  October 06, 2008
  Whenever I've talked about tracing I've always used the System.Diagnostics trace listeners in the example.