WCF Is Dead and Web API Is Dying – Long Live MVC 6 !!!

There are many reasons why WCF has lost its luster, but the bottom line is that WCF was written for a bygone era and the world has moved on. There are some narrow use cases where it still might make sense to use WCF, for example, message queuing applications where WCF provides a clean abstraction layer over MSMQ, or inter / intra process applications where using WCF with named pipes is a better choice than .NET Remoting. But for developing modern web services, WCF is as dead as a doornail.

Didn’t get the memo? Unfortunately, Microsoft is not in the habit of annoucing when they are no longer recommending a specific technology for new application development. Sometimes there’s a tweet, blog post or press release, as when Bob Muglia famously stated that Microsoft’s Silverlight strategy had “shifted,” but there hasn’t to my knowledge been word from Microsoft that WCF has been quietly deprecated.

One reason might be that countless web services have been built using WCF since its debut in 2007 with .NET 3.0 on Windows Vista, and other frameworks, such as WCF Data Services, WCF RIA Services, and self-hosted Web API’s, have been built on top of WCF. Also, if you need to interoperate with existing SOAP-based web services, you’re going to want to use WCF rather than handcrafted SOAP messages.

Read full article by Tony Sneed – Click Here.

In summary, you should avoid WCF like the plague if you want to develop REST-ful web services with libraries and tools that support modern development approaches and can be readily consumed by a variety of clients, including web and mobile applications.  However, you’re going to want to skip right over ASP.NET Web API and go straight to ASP.NET 5, so that you can build cross-platform web services that are entirely host-independent and can achieve economies of scale when deployed to the Cloud.

Hope this will help !!!

“Article of the day” @ ASP.NET Microsoft Website for Dec 22 , 2014

Hi All,

Happy to announce that my article entitled “WCF Security – How do I restrict user access to methods in WCF?” has been selected as “Article of the day” @ASP.NET Microsoft Official Website for Dec 22, 2014.

You can see at : http://www.asp.net/community/articles

Article of the day – Dec 22, 2014 on http://www.asp.net

Thank you very much to all my readers and well wishers who has inspired me to write useful content on this blog. I will continue this going forward as well.

With Regards
Sandeep Ramani

WCF Security – How do I restrict user access to methods in WCF?

Authentication verifies that a users is who he claims to be. This can be done in a couple of ways: certificates, username/password, windows credentials. Authorization will decide what an authenticated user is allowed to execute.

Implementing restricted access to WCF service can be done in a couple of ways:

Method 1: Mark methods with the declarative PrincipalPermissionAttribute to restrict access to certain roles or users.

Method 2: Imperatively check the credentials of the current user.

Method 3: Custom implementation of ServiceAuthorizationManager.

Method 1 & 2 have the drawback that they result in a lot of duplication when you have multiple service methods.

In WCF to implement authorization in a generic way the “ServiceAuthorizationManager” is used. The ServiceAuthorizationManager object is used to perform the access check and determine whether the claims associated with the client satisfy the requirements necessary to access the service method.

Let’s see some of the methods to restrict user access to some methods with examples.

Example 1: To restrict access of WCF service to users of the windows group “Administrators” using ServiceAuthorizationManager.

We need to override the method “CheckAccessCore” of ServiceAuthorizationManager class.

public class MyServiceAuthorizationManager : ServiceAuthorizationManager
    protected override bool CheckAccessCore(OperationContext operationContext)
            ServiceSecurityContext securityContext = operationContext.ServiceSecurityContext;
            WindowsIdentity callingIdentity = securityContext.WindowsIdentity;

            WindowsPrincipal principal = new WindowsPrincipal(callingIdentity);
            return principal.IsInRole("Administrators");
        catch (Exception)
            return false;

Now that our custom ServiceAuthorizationManager has been implemented, we need to hook it into the WCF pipeline. The most easy way to do is, by using the web.config or app.config file.

    <!-- Define service and endpoints Here -->
            <behavior name="MyServiceBehavior">
                <serviceAuthorization serviceAuthorizationManagerType="MyNamespace.MyServiceAuthorizationManager, MyAssembly" />

Example 2: Allow specific users to access few methods of WCF Service using ServiceAuthorizationManager.

In your custom Authorization class, you will have to override the CheckAccessCore method as shown below. In there you can check for the custom attribute [Note: Create custom attribute with whatever properties you want]

Decorate the relevant methods with your custom attribute rather than PrincipalPermission.

Now inspect the custom attribute and perform any functions. For example, if the custom attribute’s “AllowAll” flag is set, you might skip the role check. Otherwise, you might get the user’s windows identity and check they are in the particular role.

protected override bool CheckAccessCore(OperationContext operationContext)
        string action = operationContext.IncomingMessageHeaders.Action;
        DispatchOperation operation = operationContext.EndpointDispatcher.DispatchRuntime.Operations.FirstOrDefault(o => o.Action == action);
        Type hostType = operationContext.Host.Description.ServiceType;
        MethodInfo method = hostType.GetMethod(operation.Name);
        var myCustomAttributeOnMethod = method.GetCustomAttributes(true).Where(a => a.GetType() == typeof (MyCustomAttribute)).Cast<MyCustomAttribute>();

Example 3: Restrict access to WCF operations to specific Windows users using PrincipalPermission attribute?

Use the following steps to restrict access to specific Windows users:

1. Open the Computer Management Windows applet.

2. Create a Windows group that contains the specific Windows users to which you wish to give access. For example, a group can be called “CalculatorClients”.

3. Configure your service to require ClientCredentialType = “Windows”. This will require clients to connect using Windows authentication.

4. Configure your service methods with the PrincipalPermission attribute to require connecting users be members of the CalculatorClients group.

[PrincipalPermission(SecurityAction.Demand, Role = "CalculatorClients")]
public double Add(double a, double b)
    return a + b;

Example 4: Restrict access to WCF operations to specific Windows users using PrincipalPermission attribute using a certificate

You can also use the PrincipalPermissionAttribute class to control access to a method if the client credential type is a certificate. To do this, you must have the certificate’s subject and thumbprint.

1. Apply the PrincipalPermissionAttribute class to the method you want to restrict access to.

2. Set the action of the attribute to SecurityAction.Demand.

3. Set the Name property to a string that consists of the subject name and the certificate’s thumbprint. Separate the two values with a semicolon and a space, as shown in the following example:

// Only a client authenticated with a valid certificate that has the
// specified subject name and thumbprint can call this method.
    Name = "CN=ReplaceWithSubjectName; 123456712345677E8E230FDE624F841B1CE9D41E")]
public double Add(double a, double b)
    return a + b;

4. Set the PrincipalPermissionMode property to UseAspNetRoles as shown in the following configuration example:

  <behavior name="MyServiceBehavior">
  <serviceAuthorization principalPermissionMode="UseAspNetRoles" />


From above all solutions, I feel ServiceAuthorizationManager is a clean way to implement authorization at the service level.

Happy Programming !!!

Jay Ganesh

Useful References:

Difference between DataContractSerializer and XMLSerializer


1. WCF uses DataContractSerializer attribute.

2. A practical benefit of the design of the DataContractSerializer is better performance over Xmlserializer. This is because DataContratSerializer explicitly shows the which fields or properties are serialized into XML. DataContractSerializer uses the opts-in approach i.e, selecting the members that needs to be serialized.

3. The DataContractSerializer can translate the HashTable into XML.

4. DataContractSerializer serializes private members.

5. DataContractSerializer can serialize both private and public types.

6. DataContractSerializer does not need any default constructor before serializing any type.

7. DataContractSerializer does not give more control over the generated xml structure compared to the XmlSerializer.

8. DataContractSerializer can able to serialize types that implements Idictionary.


1. Webservice uses XMLSerializer attribute

2. XMLSerializer does not provide better performance when compare with DataContratSerializer because XMLSerializer does not indicate which fields or properties of the type are serialized into XML. XmlSerializer uses opts-out approach i.e., marking the members do not need to be serialized.

3. XMLSerializer cannot translate the HashTable into XML.

4. XmlSerializer cannot serialize private members.

5. XmlSerializer can serialize only public types. If we are trying to serialize a class that is marked private, InvalidOperation Exception will be thrown by the serializer.

6. For any types that needs to be serialized by XmlSerializer must have a default constructor.

7. XmlSerializer gives more control over the generated xml structure compared to the DataContractSerializer.For ex, if a field should come as an attribute or element.

8. XmlSerializer cannot able to serialize types that implements IDictionary, for ex. Dictionary type cannot be serialized.

Happy Programming !!!

Jay Ganesh