WCF Security: WCF Performance & ProtectionLevel – Part 2

In the previous post, we have stated the several problems not being able to configure ProtectionLevel for different endpoint declaratively using configuration files. In this post, we address this issue and thereby, describe how to specify ProtectionLevel for multiple endpoints of a service using .config file.

Outline. In this post, we start by stating motivation of specifing ProtectionLevel for multiple endpoints of a service declaritvely instead of programmatically. Then, we discuss the steps to achieve it.

Motivation: ProtectionLevel for Multiple Endpoints

Basically, ProtectionLevel enforces a security requirement on request and response messages in the channel, and all the consumer of the message must conform to that requirement; anything otherwise results in runtime exception. In the last post, we have described how to configure ProtectionLevel at different level of WCF messaging stack and observed that it can only be set programmatically in the contract of a WCF service, which unfortunately has impacts on all the preconfigured bindings.

For instance, consider that we would like to have two different endpoints to use different ProtectionLevel. In addition, we want to make it configurable so that we can the security behavior of the endpoint conveniently after it has been deployed.

Are these requirements practical? To answer that, consider following case: we have only one endpoint and we are using message level security with wsHttpBinding (or ws2007httpbinding preferable one for internet based WCF Service). For internet users consuming this service, we are using ProtectionLevel.EncryptAndSign because of the security requirement imposed for our application. However, in case of local intranet, we don’t want to take the overhead of
ProtectionLevel.EncryptAndSign rather would like to use ProtectionLevel.Sign to make the service a bit more responsive and efficient by getting rid of the overhead of encryption of requests and responses. Most importantly, we don’t need ProtectionLevel.EncryptAndSign for the messages in this context as per security policy. Out of the box, there is no features available that can enable the use of different ProtectionLevel in these cases.

Obviously, there is one naive approach to host to service twice by compiling the code in 2 different ProtectionLevel. At 1 to 10 scale, how would you rate this solution ? Ok , then let’s move on…

Thus, what we need is to make two different endpoints to work with different ProtectionLevel, and using custom endpoint behavior, it can be achieved. Thus, the internet users will be able to use the wsHttpBinding with default ProtectionLevel, while the intranet users use the less secure– ProtectionLevel.Sign. The next section shows how to achieve this.

ProtectionLevel Configuration via Custom Endpoint Behavior

To do this, we have following these steps.First we have to create a Custom EndpointBehavior by implementing IEndpointBehavior as below –

Then, we create a BehaviorElement by extending BehaviorExtensionElement to make the behavior configurable through config file.

Thus the coding part this done. Let’s start configuring. To do so, first thing that needs to be done is to add a behaviorExtensions inside system.serviceModel>behaviorExtensions specifying the newly created custom Endpoint behavior :

Then, we create a endpoint behavior like below:

Now, if we need to use a similar ProtectionLevel that we configured at the previous step in any endpoint , we simply need to add it as behaviorConfiguration, and we are done.

More on MessageSecurityBehavior

So far, we have described how to configure ProtectionLevel at runtime. Next we explain MessageSecurityBehavior. By changing the ChannelProtectionRequirement of an Endpoint, the new custom behavior impacts requests and responses of the channel. Moreover, the contract also binds to the configured ProtectionLevel. Then, the two different MessagePartSpecification was created, where 1st one is an empty MessagePartSpecification, and 2nd one refers to the MessagePartSpecification which contains body.

Depending of different value ProtectionLevel, the MessagePartSpecification are set to ChannelProtectionRequirements.

For instance, in case ProtectionLevel.Sign, in OutgoingSignatureParts and IncomingSignatureParts of ChannelProtectionRequirements MessagePartSpecification that included Body is being added to be signed from client to the server and again back to client from server. However, in this case , encryption is not needed, so in OutgoingEncryptionParts and IncomingEncryptionParts , empty MessagePartSpecification is added, and that results in unencrypted messages.

Conclusion

In this post, we show how to declaritively specify the ProtectionLevel for multiple endpoints exposed by a WCF service. Though it’s not difficult to update the ProtectionLevel at runtime, we must note that client and server always conform to the ProtectionLevel requirement, and as a consequence, updating the ProtectionLevel at runtime might results in updating the clients configuration/code.

Additional Links

  1. WCF Security: WCF Performance & ProtectionLevel – Part 1 : https://adilakhter.wordpress.com/2009/08/06/wcf-security-wcf-performance-protectionlevel-part-1/
  2. Custom WCF Behaviors through App.Config :http://winterdom.com/2006/10/customwcfbehaviorsthroughappconfig
  3. Configuring ProtectionLevel : http://blogs.msdn.com/drnick/archive/2008/03/10/configuring-protection-level.aspx
  4. Fundamentals of WCF Security : http://www.code-magazine.com/article.aspx?quickid=0611051
Advertisements

WCF Security: Which Binding to use in Internet based WCF Application?

 

Recently I did some diving in WCF bindings to figure out which binding to use in different kinds of scenario and what are the security implications of it for a Internet Based WCF service. As WCF concerned, definitely there are loads of options and choosing the right one in the right scenario left to us to decide. I am still continuing my research for a internet based WCF service and jot down my findings in flowchart as below .Please bear in mind that this flowchart is far from complete at this moment. I will update it as I go thru different other bindings and/or scenarios:

 


 

Links to original files: Binding.gif & WCF_BINDINGS.vsd

Please do let me know if any question come up or any new ideas to update this flowchart. Thanks for visiting the blog. I will be waiting for valuable feedback.

Comparison Of Different Channels In WCF

Few months back, we did some measurement of different WCF channel to get the precise idea about the performance in the different channel stack.

Following is the definition of the environment:

  1. WCF service and client is hosted in the same Windows 2003 Server.
  2. 537 Users exist in the system.
  3. WCF service is hosted in Windows Service.
  4. System.Diagnostics.Stopwatch is used to measure time elapsed in Millisecond.
  5. Two user credentials are used: one domain user & the local system account on which the server was running.

Primary goal was to measure the time required for each GetUsers() call( in milliseconds) for combination Binding and InstanceContextMode. That’s why, we took average of 10 Test Run (in different scenario) for each combination where in each Test Run, we call the GetUsers() 100×10 Times . Here comes the result:

Comparison of different channels
Comparison of different channels
  • From the graph above, it’s quite obvious that NetTcpBinding(PerSession) is the best performer, which is quite expected as per its channel behavior. Interestingly, if we look at the WsHttpBinding(PerSession), it is taking more time than session unaware BasicHttpBinding. There is a similarity in the trend of BasicHttpBinding (PerCall by default) , WsHttpBinding(PerCall) and NetTcpBinding(PerCall) in the first TestRun; as the first GetUsers() is setting up the whole channel stack, its taking more time than its usual time. On the other hand, WsHttpBinding(PerSession), and NetTcpBinding(PerSession) are more consistent in every Test Run because of the reusability of the Session. We measure that 15ms is the time taken on average to create a new Application specific session in our system.

  • Following is the Chart of the average time taken per request in milliseconds for each combination:

Average time taken per request in Milliseconds
Average time taken per request in Milliseconds

I would recommend you to visit Wcf Binding Comparision List and Supported Features (Reference)
for a quick comparison of different channel in terms of Transport Protocol, Message Encoding, and Message Versioning and so on.

Hope it helps to you to choose the right channel stack for your application.

Cheers! J

Preparation for Exam 70-503 TS: Microsoft .NET Framework 3.5 – Windows Communication Foundation

Just sat for the exam 70-503 TS:  Microsoft .NET Framework 3.5 – Windows Communication Foundation yesterday. It was really fun to sit for the beta exam though it was pretty long – 64 questions in Three hours and thirty minutes. Unfortunately  result  has not been published yet .According to Prometric, I will get the result 8 weeks before MS will be releasing the Final version of the exam.

After finishing the exam, I got the idea how to score good in that exam  ABC : Address , binding and contract . If you have solid understanding in these three pillars of WCF – you will surely score well. These are the topic where you should have solid understanding before sitting for the exam –

1.       WCF service and client configuration – not using service configuration tool provided in windows sdk , rather thorough Xml.

2.       Security related configuration – Authentication and Authorization support in WCF thorough xml configuration.

3.       Service Instance – Single ,PerCall , PerSession and Thread-safety of the instance.

4.       Session and Transaction.

5.       Duplex channel.  WsDualHttpBinding.

6.       Serialization.

7.       Instrumentation of WCF service instance.

8.       Interoperability with ASMX.

Thanks for visiting the blog. Wish you luck in the Exam. J