Random ramblings about Technology : WCF

Suppressing Personal Identifiable Information (PII) in WCF log files

martijnh — Mon, 18 Aug 2008 23:00:00 GMT

Given the vast amount of information transported between systems in today's enterprise environments, a lot of which is considered either private (addresses, social security numbers, credit card information, mortgage and pension plans, etc) or of high business value, information security is key.

From the release of WCF, it has brought us tremendous flexibility and allowed development teams to be almost completely agnostic of the way information is transported between point A to point B, focusing on adding business value instead.

Another great feature WCF brings us is runtime troubleshooting. In WCF, an administrator can simply enable logging to troubleshoot an environment which is in production.

Although a great feature for troubleshooting, Personal Identifiable Information (PII) you care about deeply while on the wire (using transport and message-level security to protect it) is available in plain text if logging is turned on at the server side.

WCF's logging features currently filter out specific PII by default (only if the message is not malformed). However, this functionality is not exposed to the developer.

Consider the following scenario:

You want the administrator to be able to monitor messages for auditing, logging or troubleshooting purposes;
certain information is considered PII and should not show up in the log files.

You could write your own logging subsystem and hook it in to your services. This takes a lot of work, is error prone, needs custom maintenance, documentation, etc.

My proposal for the scenario:

Use a behavior which
- introspects the published ServiceEndPoints for published OperationDescriptions and the used DataContracts,
- finds public properties on the DataContract marked as PII;
- instructs the WCF logging runtime to ignore the contents of the specified message elements.
configure the behavior through code (this is not generally considered a best practice, but the security needs of the service outweighs the flexibility needs of configuration);

Let's have a look at how the solution works:

Take a DataContract, e.g. PurchaseOrder and apply an attribute (PII) on each property which represents PII.

Next, add a PIIProtectionBehavior attribute to your service implementation class

You're done. The PIIProtectionBehavior attribute is also an IServiceBehavior implementation which performs the introspection on the EndPoints.

The result when logging is turned on:

As you can see, 'CreditCardnumber' is no longer logged, it just displays '<-- Removed -->' .

I've attached the sample code, hope it's useful!

Ofcourse, the normal disclaimers apply, the accompanied sample is for educational purposes only, it has not gone through rigorous testing, might contain bugs due to limited testing (me ;-)), etc. Please see the sourcecode for further remarks.

Adding a new BizTalk Server Isolated Host needs a new Application Pool

martijnh — Wed, 23 Jul 2008 12:29:00 GMT

Recently, we tried creating a secondary Isolated Host to separate receive and send processing for WCF. After reconfiguring the servers, we were faced with the "Receive location for address '' not found. (The BizTalk receive location may be disabled)". Puzzled, we looked around for configuration issues. After some reading (http://technet.microsoft.com/en-us/library/aa559328.aspx), we remembered a new isolated host needs a new application pool. Adding another application pool to the mix the the new host fixed our trouble... Jotted down for posterity ;-)

Testing WCF service implementations

martijnh — Thu, 17 May 2007 14:21:00 GMT

When writing WCF implementations, or any code for that matter, testing is an important part of the process. This week, I was building tests for implemented WCF services and had difficulty aligning all the external dependencies of the tests (running hosts, configuration settings, behavior component references, etc). As a result, I set up my WCF services to be self-hosted services, run from the context of the test itself. This has several advantages, and some pitfalls. The advantages:

· Isolation, the test has external dependencies only to the actual service implementation.

· No manual setup running hosts to ensure they are available, the test ‘just works’.

The pitfall might be:

· Configuration settings could become out-of-sync. Because the host of the service implementation runs within the context of the test and thereby it’s AppDomain, you need to configure the service ABCs within the test configuration file. This could mean over time you’d get configuration settings for the tests no longer in sync with the actual host.

However, because the scope of the tests is under your control and so is it’s configuration, the described pitfall might not pose an issue.

In order for the test to host it’s own instance of the services to be tested I created a generic container. It’s a simple, but effective, class which can easily host different service types (all tracing and the IDisposable implementation removed for clarity):

/// <summary>

/// Defines a generic implementation of a runnable background host.

/// </summary>

/// <typeparam name="T">The service to run within the host.</typeparam>

public class RunnableBackgroundHost<T> : IDisposable where T : class, new()

{

internal AutoResetEvent stopEvent = new AutoResetEvent(false);

/// <summary>

/// Starts the host on a new thread.

/// </summary>

public void Run()

{

ThreadPool.QueueUserWorkItem(

new WaitCallback(delegate(object state)

{

using (ServiceHost host = new ServiceHost(typeof(T)))

{

host.Open();

stopEvent.WaitOne();

host.Close();

}

}));

}

/// <summary>

/// Stops the running host.

/// </summary>

public void Stop()

{

stopEvent.Set();

}

Using this class, testing services become quite easy. Set up the host before starting the test:

[System.Diagnostics.CodeAnalysis.SuppressMessage(

"Microsoft.Performance",

"CA1812:AvoidUninstantiatedInternalClasses"), TestClass]

class HostInit

{

protected static RunnableBackgroundHost<Service1> service1;

protected static RunnableBackgroundHost<Service2> service2;

[AssemblyInitialize]

public static void AssemblyInitalize(TestContext context)

{

service1 = new RunnableBackgroundHost<Service1>();

service2 = new RunnableBackgroundHost<Service2>();

service1.Run();

service2.Run();

}

[AssemblyCleanup]

public static void AssemblyCleanup()

{

service1.Stop();

service2.Stop();

}

And set up your test, using a generated proxy (svcutil) and assuming the service is alive:

[TestClass]

public class Service1Tests : IDisposable

{

private Service1Client service1Client;

[TestInitialize]

public void TestInitialize()

{

service1Client = new Service1Client();

}

[TestMethod]

public void TestService1Method1()

{

Service1Request request = new Service1Request();

request.Id = "1";

Service1Response response = service1Client.Method1(request);

Assert.IsNotNull(response, ErrorMessages.NullResponse);

Assert.AreEqual<int>(

response.Field,

ErrorMessages.NonMatchingId);

}

ErrorMessages is a simple resource file containing the messages the test would display in case of failure.

What the test framework does in this case:

· Call the static method HostInit.AssemblyInitalize marked with [AssemblyInitialize].

· For every class within the test marked with [TestClass]

o Call any instance method marked with [TestInitialize].

o Run any method marked with [TestMethod].

o ...

· Call the static method HostInit.AssemblyCleanup marked with [AssemblyCleanup].

Within the test configuration file, configure both the service host and the client:

<system.serviceModel>

<endpoint

address="http://localhost:8889/Services/Service1"

binding="basicHttpBinding"

contract="IService1" />

</client>

<endpoint

address="http://localhost:8889/Services/Service1"

binding="basicHttpBinding"

contract="IService1" />

</service>

</services>

</system.serviceModel>

That’s the basic setup. You can now easily test different services by defining the tests for it in it’s own class using it’s own generated client proxy and adding the service to the HostInit class. You could test behaviors by adding them to the configuration file and writing a test for them if they can be tested from the outside.

Just press SHIFT+ALT+X to run the test in the debugger. No console windows popping up, your test just executes :).

WCF Message validation (1) – WCF samples to the rescue

martijnh — Sun, 13 May 2007 14:12:00 GMT

Recently, I needed to validatie messages going into a WCF service. It turned out the WCF samples are a rich source of knowledge and I found a sample which performs XMLSchema-based validation in \TechnologySamples\Extensibility\MessageInspectors.

The sample contains a few classes:

ClientValidationException.cs

Defines exceptions where validation fails clientside

SchemaValidationBehavior.cs

Defines an implementation of IEndpointBehavior in order to be an extender for defined endpoints

SchemaValidationBehaviorExtensionElement.cs

Inherits from BehaviorExtensionElement, used for configuration-time binding

SchemaValidationMessageInspector.cs

Contains the actual validation code, implementing IClientMessageInspector and IDispatchMessageInspector.

ValidationFault.cs

Defines FaultExceptions used within the code.

The sample uses a property called Schemas within it’s configuration, allowing us to define which schemas should be taken into account when validating.

</schemas>

</schemaValidator>

That’s great, but as you all probably know, WCF services have the ABC’s: Address, Binding and Contract. What I actually wanted the behavior to do was validate my message against the actual Contract of the endpoint the validator was working on.

In order for this to work, I did two thing:

1. I removed all “Schemas” configuration and arguments from the code.

2. I modified the SchemaValidationBehavior class to validate the actual contract.

The first steps should be self-explanatory, but the second I want to elaborate on. What I actually did was modify the methods ApplyClientBehavior and ApplyDispatchBehavior. The sample took the configured Schemas property to create the actual SchemaValidationMessageInspector:

SchemaValidationMessageInspector inspector =

new SchemaValidationMessageInspector(

schemaSet, validateRequest, validateReply, false);

I wanted to dynamically use the endpoint contract:

WsdlExporter exporter = new WsdlExporter();

exporter.ExportContract(endpoint.Contract);

SchemaValidationMessageInspector inspector =

new SchemaValidationMessageInspector(

exporter.GeneratedXmlSchemas,

validateRequest, validateReply, false);

After modifying both methods to perform this kind of setup, it was easy to configure validation based on the endpoint contract (some elements abbreviated for clarity):

<system.serviceModel>

<endpoint

address="SomeAddress"

binding="wsHttpBinding"

contract=" ISomeService"

behaviorConfiguration="SomeServiceEndpointBehavior" />

</service>

</services>

<SchemaValidator

validateRequest="True"

validateReply="True" />

</behavior>

</endpointBehaviors>

</behaviors>

<add

name="SchemaValidator"

type="SchemaValidationBehaviorExtensionElement, ..."/>

</behaviorExtensions>

</extensions>

</system.serviceModel>

That’s it, now we have a service endpoint validated based on it’s WSDL contract.

The sample code is attached for your enjoyment.