SymmetricKeyEncryption in WSE 2.0 ( part 2 )

As promised, i would talk about a second approach to achieve symmetric key based encryption in WSE 2.0.

First, you need to create a simple hello world web service with a client project and a web service project. Assuming you already know how to do it.

Now add the symmetric key based encryption using WSE 2.0 by introducing a new type of token.  OK.  Use WSE setting tool to enable WSE in both VS projects.  Then you need to define a new class for this symmetric key token, which needs to derive from SecurityToken class, and defines some key properties, such as Key for key material and key algorithm, GetXml() and LoadXml() for token serialization, i.e. the wire format of this new token.

Here is one of the examples where you can mange the key property. 

public

override KeyAlgorithm Key

{

      get

{

KeyAlgorithm algo = KeyAlgorithm.Create("AES128");

((SymmetricKeyAlgorithm)algo).KeyBytes = new byte[16]{my secret goes here};

               return algo;

}

}

A second class you need to define is a new symmetric key token manager which derives from SecurityTokenManager class.  The security  token manager is mainly used on the receiving end for the WSE engine to process the token and retrieve the right key.  LoadTokenFromXml() is one of the important methods that needs to be overriden.  Its implementation could be something like

public

override SecurityToken LoadTokenFromXml( XmlElement element )

{

return new SymmetricKeyToken(element);

}

 Now a little bit hard part is to register your token manager in the configuration section.  If you token's token wire format will look like

<sym:SymmetricToken xmlns:sym="https://tempuri.org/">something</sym:SymmetricToken>

Then its configuration section could look like

<

securityTokenManager type="Service1.SymmetricKeyTokenManager, Service1" xmlns:s="https://tempuri.org/" qname="s:SymmetricToken"/>

provided the new token manager class is named as SymmetricKeyTokenManager, its namespace is Service1, and it is compiled into a dll called Service1.

Note here the token's qname is different from token's token type as token type is a uri instead of a qname. The xml token is registered using its qname instead of its token type.

Now the code above hard coded the secret into the symmetric key token's implementation, which is not a good idea.  You could certainly add a constructor which takes in the secret as an argument, and on the receiving end, it could use the configuration to configure the secret.  For simplicity, i didn't include it in the example above.  For those hard-core WSE veterans, you might want to make the Symmetric Key Token a IDerivableToken, so the sub-seqent message can use a Derived Key instead of the same key material over and over again.

This approach is considered better than the SCT approach that i described in part 1 as it won't interfere the SecureConversation feature.

Good luck!