This past week I got to experiment with securing WCF (Indigo) Operations with AzMan. We ended up with something like this:
[ServiceContract]
public class ICustomerService {
[OperationContract]
[FaultContract(typeof(OperationPermissionFault))]
[Authorization(“FindCustomer”)]
Customer FindCustomer(FindCustomerRequest request);
}
Decorating the operations on our WCF Service with an AuthorizationAttribute ensures that the user calling the service has the appropriate permission to run the operation. The AuthorizationAttribute is an operation behavior (IOperationBehavior) that injects a custom IParameterInspector into the processing pipeline for the given WCF operation. The Parameter Inspector then does an authorization check against AzMan for the user that called the service. All cool stuff.
If your interested in integrating with AzMan for authorization checkout Sam’s most excellent post on the topic entitled: “How To: STS/Windows Authentication with ADAM/AD, Roles in AzMan with WCF”.
Today I’d like to talk about a few of the extensibility points within WCF. I should note that the descriptions below are my interpretation of how each of the extensibility points are meant to be used and not guaranteed to be correct since I couldn’t find any real definitions anywhere 
During my investigation I found a couple different points of extensibility within WCF. The first extensibility point allows you to change the behavior of your services, endpoints, and operations and have the appropriate name of “Behaviors”. The second extensibility point I came across was what I’m going to refer to as “Inspectors”. Inspectors can be added to the processing pipeline of WCF and can control how messages are processed when they enter the pipeline via a request as well as when the messages go back out the other end when sending a response.
Behaviors
While investigating behaviors I came across the following three interfaces: IServiceBehavior, IEndpointBehavior, and IOperationBehavior. The astute reader among you will surely see that these three interfaces allow developers to extend the beahvior of services, endpoints, and operations! Often times the behavior is responsible for configuring “Inspectors” that will then be injected into the processing pipeline. Whether you choose a IServiceBehavior, IEndpointBehavior, or IOperationBehavior depends on the level of granularity by which you want to alter the behavior of WCF.
If you interested in changing the behavior of WCF at the service level you’ll create your own IServiceBehavior. Often times if you create a service behavior you’ll want to apply the behavior to all the endpoints within this service which is where the IEndpointBehavior comes in. If you want to be a little more fine grained you may forgo the IServiceBehavior and IEndpointBehavior in favor of the IOperationBehavior. An IOperationBehavior can be applied on a per Operation basis and are typically done so via attributes (for example the AuthorizationAttribute mentioned above).
While behaviors are the means by which you change the behavior of WCF they often times aren’t the ones doing the actual work. Enter Mr. Inspector.
Inspectors
Inspectors are how you actually change and/or alter the processing pipeline of Indigo. By creating a IDispatchMessageInspector you can pre-process messages as they enter and exit the WCF pipeline. At the IDispatchMessageInspector level you’re dealing with messages before they’ve found their final destination (aka: Operation). Often times your IServiceBehavior or IEndpointBehavior will add a custom IDispatchMessageInspector to the Dispatch Runtime of Indigo. Pre-processing of incoming messages can be done in the AfterReceiveRequest method of your IDispatchMessageInspector, while pre-processing of repy messages can be done in the BeforeSendReply method.
IDispatchMessageInspectors are typically injected into the WCF pipeline in the ApplyDispatchBehavior method of your custom IServiceBehavior or IEndpointBehavior class by adding the message inspector to the “DispatchRuntime.MessageInspectors” collection.
If your developing something more fine grained then the service or endpoint level you’ll likely be injecting IParameterInspector’s into the processing pipeline via a custom IOperationBehavior class. Once a WCF message has gone through the necessary processing and found a home (aka a matching OperationContract) you have one more chance to apply some of your own custom logic via your very own IParameterInspector. The parameter inspector allows pre and post processing of messages via the BeforeCall and AfterCall method. The BeforeCall method is called just before the message is dispatched to the service operation and the AfterCall method is called just before the response message is sent from the service operation back to the client.
In order to do our authorization checks at the operation level we created a custom IParameterInspector that calls out to AzMan and validates that the user has the necessary permissions. If the user does not have permissions we throw a OperationPermissionFault to our client which prevents the operation on the service from executing.
Wrapping Up
While this post overviews several of the extensibility points within WCF it is NOT an exhaustive list. It also doesn’t go into a whole lot of detail regarding the specifics of how all of the above is done in code. I’ll be looking to do some additional posts which detail how all of the above is done in code in the next couple of weeks. Additionally I’ll be digging into some of the extensibility points which I have not investigated thus far. If your interested in a full list of extensibility points within WCF checkout Christian Weyer WCF Extensibility Cornucopia post.
If you have any questions or would like to see sample code for something particular drop me a line and I’ll see what I can do. If your starting to work with WCF I strongly encourage you to start digging into the details of their extensibility model…it kicks ass! 