Encryption Handler

As promised awhile back we'll take a look at the EDAF handler we created in order to encrypt and decrypt data within our messages.

To do so we built the handler in an assembly called Compassion.Services.EDAF.Handlers.Security.dll. This is an AtomicHandler (it doesn't hold state between invocations) that can be configured either in the before or after pipeline of service action calls in order to encrypt or decrypt messages using various key providers.

For example, the configuration of the handler in the ProcessConstituentRequest façade pipeline in order to encrypt messages before they are saved in the ConstituentRequest and ServiceManager databases.

<before>
 <handler handlerName="MessageEncryptor">
  <ci:loggerSettings localValue="US" 
    keyDir="C:\CompassionServices\Config\      
     Keys\CIPublicOnlyKey.xml" 
    operation="Encrypt"  
    message="Request"  
    provider=
      "Compassion.Services.Security.Common.KeyFileProvider,
    Compassion.Services.Security.Common, 
    Version=1.0.0.0, Culture=neutral, 
    PublicKeyToken=7674363010ccf400" />
 </handler>
</before>

As you can see the handler is configured in the before pipeline and is set to encrypt the Request message using the KeyFileProvider. The handler uses reflection to load the key provider dynamically and pass in constructor arguments such as the file path and asymmetric algorithm. At this time the handler hard codes the instantiation of the RSACryptoServiceProvider since it is the only AsymmetricAlgorithm implemented in v1.1 of the .NET Framework.

In order to encrypt data on the way out of a service call (for example for an operation that selects payment data the handler would be configured like so:

<after>
 <handler handlerName="MessageEncryptor">
  <ci:loggerSettings localValue="US" 
   keyDir=
     "C:\CompassionServices\Config\Keys      
      CIPublicOnlyKey.xml" 
   operation="Encrypt"  
   message="Response"  
   provider=
    "Compassion.Services.Security.Common.KeyFileProvider,
   Compassion.Services.Security.Common, 
   Version=1.0.0.0, Culture=neutral, 
   PublicKeyToken=7674363010ccf400" />
 </handler>
</after>

One of the interesting things about the implementation of this handler is that the ObjectEncryptor deals with objects whereas EDAF pipelines pass XmlDocument instances to their handlers via the Execute method. As a result, the handler is responsible for pulling the type information out of the EDAF configuration file and using it deserialize the type and pass it to the encryptor.

In the previous post on this topic a reader asked why we didn't use WS-Security in order to encrypt the message. That's a great question and the answer is that if we had used WS-Security we could certainly have encypted the message body but this would not have allowed us to view the message when it was logged in our infrastructure. In other words, we want visibility into the all parts of the message except those explicitly marked as needing protection.