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 validating CustomerCredential 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 wsHttp binding for our service. In order to introduce a wsHttp binding, make an entry in the web.config file as follows:
<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 as MessageBodyMember in the Message Contract CustomerCredential. Since we have set protection level to “EncryptAndSign” for MessageHeader, the SecurityToken has been signed and encrypted. Also, the MessageBodyMember CustomerID is visible as its protection level is set to “None”.
Now check the response message. The returned Message Contract AccountsInfo does not have any MessageHeader. 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 messagebody becomes signed and encrypted.
History
- 21st January, 2012: Initial version
