Chris Keyser, a new blogger from the .NET Architecture Team, has started a series of posts on the how to use WS-SecureConversation and the SecurityContextToken in a server farm situation.  WSE takes care of making this happen through policy and configuration (as I’ve described before), so you don’t need to worry about the plumbing, but it is an interesting architectural decision about how you handle things in a server farm scenario.

Here’s some background on the ‘plumbing’:

• The Security Context Token (SCT) is a fast, light-weight security token that can provide message-level secure communication across multiple calls between a sender and a receiver.  It is fast because it uses a shared symmetric key and it can also reduce the size of the SOAP message headers.  It is the basis for the WS-SecureConversation specification.
• As the WSE 2.0 Security Settings Wizard recommends, using a SCT makes sense in cases where there will be multiple messages exchanged.  This is because the first message exchange is spent on acquiring the Security Context Token from a Security Token Service that issues security tokens.  The client has to send a RequestSecurityToken message to the token issuer.  This message is signed with a token from the sender so that the sender’s identity and credentials can be checked before the SCT is issued in the RequestSecurityTokenResponse message.
• WSE 2.0 can automatically support Security Context Tokens, setting up an automatic Security Token Service that handles the issuing of these tokens (all through the element in the WSE config section). 
• The SCT is fast because it uses a shared symmetric key between the sender and the receiver.  This is much faster than using asymmetric (public/private) keys.
• The SCT can reduce the size of the message headers in two ways.  First, the SCT itself is pretty small, with only on mandatory element, an Identifier.  Second, WSE supports the automatic caching of the symmetric key and the original token (the base token) used to request the SCT so that they don’t need to be sent each time (a reference is just included where it is needed).

The question is, if the symmetric key and the original token are cached between the sender and receiver, how will this work if the receiver is part of a web farm?  Chris mentions three ways to deal with this issue:

• Pin the sender’s session to a particular receiver within the web farm (here).
• Store the session in some area that all of the receiver’s within the web farm can reach
• Place the session information inside the SCT.

I’m particularly interested in the last option.  Both WS-Addressing (in the ReferenceParameters section) and the SCT provide mechanisms for providing extended information to a receiver.  In a sense both can provide ‘cookie’ style state information.  I wonder if Chris has some guidance about which approach to use and when.