The second constructor is used by the MerkleTokenManager when WSE finds a MerkleToken in a message and calls LoadTokenFromXml.  The XmlElement looks like the RawData element created by the first constructor.

The final token specific part I'll discuss is the Key property.  This takes the random number, looks up the key and then creates an AES128 SymmetricKeyAlgorithm with its KeyBytes property set the key.

The token object does the heavy lifting, in the next part we'll look at how the client and server actually use it.

Merkle's Puzzles were developed by Ralph Merkle in 1974 and are one of the first demonsttations of a public key cryptosystem.  The public key consists of a set of n puzzles.  Each puzzle contains a random number and a private key that encrypts that puzzle.  To encrypt a message a client would randomly select a puzzle and then launch an attack to decrypt it.  The message is encrypted with the private key and the ciphertext is sent along with the random number, which is in the clear.  The server maintains a mapping of which random number was encrypted with which key, so to decrypt it simply looks up the key and decrypts it.  If it takes the client n time to crack a puzzle, and since an eavesdropper doesn't know which puzzle the client selected, the eavesdropper has to crack all the puzzles.  This would take n2 time, which is an advantage but a very small one in the cryptographic world and why Merkle's Puzzles are only of academic and historic interest.

In that academic interest, I've implemented a MerkleToken using the custom token facilities available in WSE.  The basic design is:

• The client has a secret password shared with the service.  This is used for signing.
• The client begins by asking the service for it's puzzles.  The RST and RSTR are signed with a UsernameToken.
• Upon receipt of the first RST the service generates a set of puzzles.  Subsequent RST's receive the same set.
• Upon receipt of the RSTR the client randomly decrypts a puzzle and creates a token consisting of the key and the random number.
• During the conversation with the service, the encrypts messages with key from the previous step and signs with UsernameToken (the UsernameToken can now be encrypted with the MerkleToken).  The responses are encrypted and signed with the same tokens.

There's some obvious real world problems here that I'll describe here and then blissfully ignore. 

1. The MerkleTokens never expire, so an eavesdropper can read one RSTR, take the time to crack all the puzzles and then read everything.
2. Even though the password never goes over the wire (PasswordOption.SendNone) the signatures are vulnerable to a dictionary attack.

I've restricted myself from using tokens besides UsernameToken and MerkleToken, since if they were available it makes using the MerkleToken sillier than it already is.  This precludes encrypting the original token exchange.  This is an artifact of the lack of any infrastructure like a Merkle certificate that could vouch that puzzles belong to the service and haven't been modified.  This also means I couldn't use WSE's token issuing framework since unencrypted UsernameTokens are forbidden in RST's since WSE2 SP2.

In the coming parts I'll actually get to some code.  I used the CustomBinaryToken quick start from the WSE documentation.  Since all the more advanced quick starts use asmx, I decided to do this over tcp instead.  Also I used the code based approach instead of policy since I find it easier to experiment with code.

Out of the box, the default maximum allowed size is 4 MB.  To adjust this there are several config settings.  If the service is hosted in ASP.NET, use the <httpRuntime> element in the system.web section.  The interesting attributes are maxRequestLength and executionTimeout.  maxRequestLength is the number of KB allowed, so the default is 4096 KB (4 MB).  executionTimeout is the number of seconds until the request is killed.  So to set the max to 400 MB and timeout to 10 minutes, it would look like this:

<httpRuntime executionTimeout="600" maxRequestLength="409600"/>

If the service is hosted in TCP, then WSE provides similar config entries:

<microsoft.web.services2>
  <messaging>
   <executionTimeout value="-1"/>
   <maxRequestLength>-1</maxRequestLength>
  </messaging>
 </microsoft.web.services2>

executionTimeout and maxRequestLength both have the same units as their ASP.NET counterparts, but they have the extra option of specifying -1 to say no maximum length, and no timeout.

Say you're successfully configured your service to handle large attachements, but some attachments are still too large and you can't just throw more memory at the problem.  Now you'll have to write some code, specifically your own chunking algorithm.  By splitting the attachment into chunks you can send several manageable attachments instead of one gargantuan attachment.

public class WsdlProxy : SoapClient

{

public WsdlProxy( Uri to ) : base( to ){}

public WsdlProxy( EndpointReference epr ) : base( epr ){}

public virtual SoapEnvelope RequestDescription()

{

SoapEnvelope env =

new SoapEnvelope();

// you can use the SoapMethod attribute to set this instead

env.Context.Addressing.Action = "http://schemas.microsoft.com/wse/2003/06/RequestDescription";

return base.SendRequestResponse("RequestDescription", env);

}

}

After calling RequestDescription, the wsdl is in the Body.FirstChild member of the returned envelope.

To construct the WsdlProxy, if the SoapService has a logical name (ie it uses the SoapActor attribute) as well as a physical name, create an EndpointReference and use that constructor, otherwise simply create a Uri constuct it that way.