WCF Service Method Level Security using Message Contract

January 31, 2012 § Leave a comment

 

 

Introduction

This article illustrates how to implement security for a service method, in the context of custom authentication, confidentiality and integrity, using Message Contract. The message is packed with authentication information at the client side in the MessageHeader. The Service intercepts this message and validates the credibility of the consumer client. Besides, we will also check, using Message Contract how can sign or encrypt partial header information and all body information in a message.

Real Life Scenario

There could a service method which is passing sensitive information over the wire and you want to take some exclusive security measure for the service method in question. You can pack a security token in the relevant message header for the service method and validate the same in the service end before returning response. Also, since the information in the message is highly sensitive, you can sign and encrypt the message. We will implement this kind of service method level authentication and message level security for a specific service method, using Message Contract in this article.

Implementing the WCF Service

In order to implement the above discussed concept, we will develop a simple WCF service project. The WCF service has a GetAccountsData method which returns AccountsInfo of a customer on validatingCustomerCredential passed as input.

The types passed and returned by the service method are defined as Message Contract. In order to Sign/Encrypt the Message parts, we will use protection level. There are three basic levels of protections that exist for any part of a message:

  • None.
  • Sign. The protected part is digitally signed. This ensures detection of any tampering with the protected message part.
  • EncryptAndSign. The message part is encrypted to ensure confidentiality before it is signed.

In order to set protection level, use System.Net.Security namespace.

The CustomerCredential Message Contract contains a MessageHeader element SecurityToken, which is being validated at service end.

One thing to keep in mind, the SOAP Body has only one protection level, even if you have multiple body parts with different protection levels. In case of AccountsInfo Message Contract, the highest protection level off all body parts will be taken (in our case, EncryptAndSign). SOAP headers can have different protection levels. I have deliberately set different protection level in Message body in order to establish this behavior. We will verify this on checking the HTTP traffic.

Implement the service method. If the SecurityToken matches, the method returns AccountsInfo for the customer, otherwise throws security exception.

The default WCF binding BasicHttpBinding does not support protection level. We need to introduce a wsHttpbinding for our service. In order to introduce a wsHttp binding, make an entry in the web.config file as follows:

 Collapse | Copy Code
<services>
      <service name="MyWCFService.MyService">
        <endpoint address="" binding="wsHttpBinding" contract="MyWCFService.IMyService"/>
        </service>
</services>

Right click -> View in Browser on the file MyService.svc in order to check the WSDL generated by the WCF service.

Publish the Service in Internet Information Server(IIS)

We could have called the service without publishing it in IIS. But at the end, we are also going to check the Sign/Encryption of messages. We will be checking HTTP traffic using Fiddler tool while the service is being consumed by some client application. For this purpose, we need to publish it in IIS (sometimes Fiddler creates problems while inspecting localhost traffic. There are workarounds for this, but it’s better to publish the service in IIS). Right click on the WCF service application project and click on publish. Create a virtual directory named WCFVW in IIS and publish the service. Modify the target location with your pc name.

Browse the newly published service in the browser:

Click on the service link and check the WSDL.

Calling the Service

We will create a simple console application in order to consume the service. Add a Console application project. Right click on the References->Add Service Reference. Type the WCF service URL in the Address box.

Once you click on OK, the stub code will be generated. Open Program.cs and add the following namespaces:

Implement the following code in order to call the service using channel factory. The SecurityToken is being set in the MessageHeader. If the credential matches, the retrieved account detail for the Customer is being printed, otherwise the Fault thrown by the service is displayed in the console.

Run the console application. The accounts information will be retrieved as the SecurityToken is matched at the service end.

Now modify the client code in order to pass a different SecurityToken.

Run the Console application. Fault will be thrown from the service due to the mismatch in the SecurityToken.

Checking Message Sign/Encryption

We are now done with the project and it is time to sniff the HTTP traffic between service and client in order to verify desired Sign/Encryption in our Message Contract. Run the HTTP data inspector Fiddler. Now, run the console application in order to call the service. Check the service request traffic:

The request traffic consists of the message parts SecurityToken as MessageHeader and CustomerID asMessageBodyMember in the Message Contract CustomerCredential. Since we have set protection level to “EncryptAndSign” for MessageHeader, the SecurityToken has been signed and encrypted. Also, theMessageBodyMember CustomerID is visible as its protection level is set to “None”.

Now check the response message. The returned Message Contract AccountsInfo does not have anyMessageHeader. It has got MessageBodyMembers with different protection level. As I have mentioned earlier, the SOAP Body has only one protection level, even if you have multiple body parts with different protection levels. In this case, the highest protection level of all body parts, EncryptAndSign is taken and the entire messagebodybecomes signed and encrypted.

 

(Source : CodeProject)

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

What’s this?

You are currently reading WCF Service Method Level Security using Message Contract at Naik Vinay.

meta

%d bloggers like this: