There are four core security features that WCF addresses:
- Confidentiality: This feature ensures that information does not go in to the wrong hands when it travels from the sender to the receiver.
- Integrity: This feature ensures that the receiver of the message gets the same information that the sender sent without any data tampering.
- Authentication: This feature verifies who the sender is and who the receiver is.
- Authorization: This feature verifies whether the user is authorized to perform the action they are requesting from the application.
What is transport level and message level security?
When we talk about WCF security, there are two aspects. The first is the data and the second is the medium on which the data travels, i.e., the protocol. WCF has the ability to apply security at the transport level (i.e., protocol level) and also at message level (i.e., data).
Figure: Transport and Message level security
Transport level security happens at the channel level. Transport level security is the easiest to implement as it happens at the communication level. WCF uses transport protocols like TCP, HTTP, MSMQ, etc., and each of these protocols have their own security mechanisms. One of the common implementations of transport level security is HTTPS. HTTPS is implemented over HTTP protocols with SSL providing the security mechanism. No coding change is required, it’s more about using the existing security mechanism provided by the protocol.
Message level security is implemented with message data itself. Due to this, it is independent of the protocol. One of the common ways of implementing message level security is by encrypting data using some standard encryption algorithm.
Advantages:
- Does not need any extra coding as protocol inherent security is used.
- Performance is better as we can use hardware accelerators to enhance performance.
- There is a lot of interoperability support and communicating clients do not need to understand WS security as it’s built in the protocol itself.
Implement transport security?
Step 1: Create a simple service using a WCF project
The first step is to create a simple WCF project. So click on New Project and select WCF Service project. By default, a WCF project creates a default function
GetData()
. We will be using the same function for this sample.
Hide Copy Code
public class Service1 : IService1
{
public string GetData(int value)
{
return string.Format("You entered: {0}", value);
}
public CompositeType GetDataUsingDataContract(CompositeType composite)
{
if (composite.BoolValue)
{
composite.StringValue += "Suffix";
}
return composite;
}
}
Step 2: Enable transport level security in the web.config file of the service
The next step is to enable transport security in WsHttp binding. This is done using the
Security
XML tag as shown in the below code snippet.
Hide Copy Code
<bindings>
<wsHttpBinding>
<binding name="TransportSecurity">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
Step 3: Tie up the binding and specify HTTPS configuration
We need to now tie up the bindings with the end points. So use the
bindingConfiguration
tag to specify the binding name. We also need to specify the address where the service is hosted. Please note the HTTS in the address tag.
Change
mexHttpBinding
to mexHttpsBinding
in the second end point.
Hide Copy Code
<service name="WCFWSHttps.Service1" behaviorConfiguration="WCFWSHttps.Service1Behavior">
<!-- Service Endpoints -->
<endpoint address="https://localhost/WCFWSHttps/Service1.svc"
binding="wsHttpBinding" bindingConfiguration="TransportSecurity"
contract="WCFWSHttps.IService1"/>
<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange"/>
</service>
In
serviceMetadata
, we also need to change httpGetEnabled
to httpsGetEnabled
.
Hide Copy Code
<serviceBehaviors>
........
.........
<serviceMetadata httpsGetEnabled="true"/>
.........
.........
</serviceBehaviors>
Step 4: Make the web application HTTPS enabled
Now that we are done with the WCF service project creation and the necessary configuration changes are done, it’s time to compile the WCF service project and host it in an IIS application with HTTPS enabled.
We will be using ‘makecert.exe’ which is a free tool given by Microsoft to enable HTTPS for testing purposes. MakeCert (Makecert.exe) is a command-line tool that creates an X.509 certificate that is signed by a system test root key or by another specified key. The certificate binds a certificate name to the public part of the key pair. The certificate is saved to a file, a system certificate store, or both.
You can get it from C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin or you can also get it from the Windows SDK.
You can type the below through your DOS prompt on “C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin”. Please note “compaq-jzp37md0” is the server name so you need to replace it with your PC name.
Hide Copy Code
makecert -r -pe -n "CN= compaq-jzp37md0 " -b 01/01/2000
-e 01/01/2050 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange
-sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
If you run the same through your command prompt, you should get a succeeded message as shown below:
Now it’s time to assign this certificate to your IIS website. So go to IIS properties, click on the Directory Security tab, and you should see the Server Certificate tab.
Click on the Server Certificate tab and you will then be walked through an IIS certificate wizard. Click ‘Assign an existing certificate’ from the wizard.
You can see a list of certificates. The “compaq-jzp37md0” certificate is the one which we just created using ‘makecert.exe’.
Now try to test the site without ‘https’ and you will get an error as shown below….That means your certificate is working.
Do not forget to enable IIS anonymous access.
Step 5: Consume the service in a web application
It’s time to consume the service application in ASP.NET web. So click on Add Service Reference and specify your service URL. You will be shown a warning box as in the below figure. When we used makecert.exe, we did not specify the host name as the service URL. So just let it go.
Step 6: Suppress the HTTPS errors
‘makecert.exe’ creates test certificates. In other words, it’s not signed by CA. So we need to suppress those errors in our ASP.NET client consumer. So we create a function called
IgnoreCertificateErrorHandler
which returns true even if there are errors. This function is attached as a callback toServicePointManager.ServerCertificateValidationCallback
.
In the same code, you can also see the service consuming code which calls the
GetData
function.
Hide Shrink Copy Code
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using WebApplicationConsumer.ServiceReference1;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography.X509Certificates;
namespace WebApplicationConsumer
{
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
ServicePointManager.ServerCertificateValidationCallback =
new RemoteCertificateValidationCallback(IgnoreCertificateErrorHandler);
Service1Client obj = new Service1Client();
Response.Write(obj.GetData(12));
}
public static bool IgnoreCertificateErrorHandler(object sender,
X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
return true;
}
}
}
Step 7: Enjoy success
Now to the easiest step, compile your ASP.NET client and enjoy success.
No comments:
Post a Comment