Enhancing Service Security Using WCF Message Inspectors

Enhancing Service Security Using WCF Message Inspectors

WCF message headers are a great source of meta data about a service and service methods. We can enhance Message headers to also include security related information.This has been an established fact.

The question comes in our minds is what are the best architecture designs to accomplish that.

In this blog we would explore the design features of such designs that makes use of Message Headers in the best optimal way.

Before we start let us take a look at standard WCF messaging architecture.

Using Message Inspectors

Message inspectors are a great way to access request messages that are going out from the client, reaching to server and the response messages that are coming out of service and heading to client.

Here is a simplified version of how that works:

As you can see from the above figure and compare that to figure about that from previous section, you will notice:
1. Message is divided into request and response messages. This essentially a more detail of actual message.
2. Messages that are coming out of client headed towards service are Request messages; and message that are coming out of service are called Response messages.
3. There are four events added that are divided into two groups. These events gives us point in time when a particular message is passed from source or reaches its destination. These events are: "BeforeSendRequest", "AfterReceiveRequest", "BeforeSendReply" and "AfterReceiveReply".

The last point mentioned above is of the utmost importance. These events are the instances where we can prepare a message that is going out from the client and interrogate a message that is coming to service to implement and ensure security.

How to implement a message inspector is beyond the scope of this post. But if you want some details, you can visit my previous post here.

Let us focus on how we can use the incoming and out going messages going through the "BeforeSendRequest", "AfterReceiveRequest", "BeforeSendReply" and "AfterReceiveReply".

Let us take look at different security implementations that use Message inspectors and Message Headers.

1. Security Token:
Using security token, we can implement a security infrastructure that is reliable, easy to maintain and yet simple enough. Following are the  main parts of such infrastructure:

• Security token provider
• Client
• Message inspector
• Message header

Here are the steps that shows how it works.

• A client requests for security token from security token provider. 
• A security token provider provides a token to client.
• Client adds the acquired security token to message header before making a service request.
• Message inspector ensures that security token is part of message headers that is sent to the service. If the message headers do not include the security token, then it throws a security exception. Otherwise it lets the message flow to service end point.
• Once server receive the request, it reads the incoming message headers and parses out the security token. 
• Using the parsed security token, the service then request the security token provider to authenticate security token.
• Service executes the requested method after successful authentication.

2. Claims:
Claims provide a granular detail of what a user is authorized to. We can use the WCF message headers and message inspectors to implement an advanced security infrastructure when used with claims.  Following are the main parts of claims based solution:

• Claims provider
• Client
• Message inspector
• Message header

Here is the system flow of how the claims-based solution will work.

• A client requests for claims to claims provider by providing its authentication details.
• Claims provider generates a list of claims based on the user authentication level.
• Claims provider sends the claims that user is entitled to to client.
• Client adds the claims that it received from claims provider to message header before making a service request.
• Message inspector on service end receives the claims that it recieved from client and generates an identity.
• Service executes the requested method under the context of the identity that was created based on the claims.

Conclusion:

As we have seen that WCF provides all the necessary tools to a viable security infrastructure. We have discussed two architecture that can be implemented to any WCF based services. A security token based architecture is simple and can be implemented on system wide basis. This solution is best for implementations where user authentication is of utmost importance. On the other hand, Claims based implementation is more granular  complex and advanced. The complexity pays off in terms of flexibility.