Tag Archives: WCF

Exposing a WCF Data Service via the Azure AppFabric Service Bus


The How


The following excerpt shows how to expose a WCF Data Service via the Azure AppFabric Service Bus, using a self-hosted ServiceHost.


using(var host = new DataServiceHost(
                     typeof(PersonsDataService), new Uri[0])){
    typeof (IRequestHandler),
      new WebHttpRelayBinding(
    Console.WriteLine("host is opened, press any key to exit");


  • PersonsDataService is the data service to be exposed;
class PersonsDataService : DataService<MyDataModel>{
    public static void InitializeService(
                           IDataServiceConfiguration config) {


  • IRequestHandler is the WCF Data Services generic service contract (see below);
  • WebHttpRelayBinding is the Azure AppFabric Service Bus binding for the “web programming model”.
  • and WithServiceBusTransportCredentials is an extension method for configuring the service bus transport credentials
public static ServiceEndpoint WithServiceBusTransportCredentials(this ServiceEndpoint edp)        {
    return edp;
public static void 
ConfigureTransportCredentials(ServiceEndpoint edp) {
    var tcred = new TransportClientEndpointBehavior();
    tcred.CredentialType = 
    tcred.Credentials.SharedSecret.IssuerName = IssuerName;
    tcred.Credentials.SharedSecret.IssuerSecret = SharedSecret;



The Why

WCF Architecture

The Windows Communication Architecture is based on two layers:

  • The Channel Model Layer is a stack of channels that operate on messages, composed by
    • Zero or more protocol channels, implementing protocols such as WS-Security.
    • One transport channel that send or receives the messages from the transport medium (e.g. TCP, pipes). This transport channel uses a message encoder/decoder to translate between the messages handled by the protocol channels and the transport’s byte streams.
  • The Service Model Layer is responsible for the translation between messages and service method calls.



WCF Data Services

WCF Data Services are layered on top of the WCF Service Model:


public interface IRequestHandler {    
     WebInvoke(UriTemplate = "*", Method = "*")]
    Message ProcessRequestForMessage(Stream messageBody);
    RequirementsMode = 
     InstanceContextMode = InstanceContextMode.PerCall)
public class DataService<T> : IRequestHandler, IDataService {
    public Message ProcessRequestForMessage(Stream messageBody){...}


Azure AppFabric Service Bus

The Azure AppFabric SDK contains several bindings to expose and consume services via the service bus, namely the WebHttpRelayBinding that uses the Web HTTP programming model. This binding defines a channel stack with a RelayHttpTransportChannelListener that opens a TCP connection to the services bus and listens to messages relayed by it.



Since the Service Bus bindings extend the channel layer and the WCF Data Services are layered on top of the Service Model Layer, their composition is straightforward.

The case of the missing binding

Today, while preparing a training session on WCF, I decided to use Eclipse’s Web Services Explorer (WSE) to view and interact with a WCF-based service (using plain WSHttpBinding).

However, after processing the service’s WSDL description, WSE showed a service with an empty binding list.

Knowing that some web services stacks don’t support WSDL descriptions divided into multiple files, I used the FlatWSDL endpoint behavior authored by C. Weyer. This behavior extends WCF’s WSDL exporting mechanism, by inlining in the WSDL document all the schemas directly or indirectly referenced by it.

Unfortunately, the behavior of WSE remained the same: it continued to show a service with no bindings. After inspecting again the generated WSDL, I observed that it was still divided into two WSDL documents: the first one with the <service> and <binding> elements, and the second one (imported by the first) with the remaining WSDL elements and the flattened schemas.

The reason for this division is explained in this post by Kirill Gavrylyuk: this division is used when there are WSDL elements (<service>, <binding>, <portType>, …) in different namespaces.

So, a solution is to put all the elements in the same namespace, which also is described in the same post.

After this change, all the WSDL elements were contained in a single document and WSE finally showed the service binding.

These are the joys of interoperability.

WCF asynchronous processing and IIS hosting

Recommending the post “WCF Request Throttling and Server Scalability“.

It contains important information regarding WCF’s asynchronous processing when hosting on IIS. For example, I was unaware that

So in the release of .Net 3.0 and 3.5, WCF implemented synchronous versions of HTTP module and handler instead of asynchronous ones

meaning that even with asynchronous service implementation (asyncpattern=true), a thread will be blocked for the duration of the request’s processing. This thread will be the ASP.NET’s thread from the CLR ThreadPool.

Since I do most of my tests and experiences using self-hosting, I didn’t have noticed this.

However, the SP1 of .NET 3.5 adds support for asynchronous HTTP modules and handlers.

Using Zermatt’s claims model on WCF: ClaimsPrincipal.Current

In the last post, I briefly presented Zermatt’s claims model. This model can be used in both WCF based services or ASP.NET based web applications.

Beginning with this post, I will describe how this new claims model is integrated into WCF, using WCF’s extensibility points, and also what are some consequences of this integration.

Once again, keep in mind that these are empirical observations of the first beta release.

One way of using Zermatt’s claims model on a service, without needing to change WCF’s default behavior, is via the ClaimsPrincipal.Current static property. In WCF, the getter method will first check if the incoming message properties (available in the current operation context) contains a property whose name is typeof(IClaimsIdentity).FullName. If not, the getter method will create and return a ClaimsPrincipal instance based on the following procedure:



  1. Retrieves all the IAuthorizationPolicy objects from the current operation context.
  2. Creates a default AuthorizationContext with the claim sets produced by the evaluation of the above IAuthorizationPolicy set.
  3. Creates one ClaimsIdentity instance for each ClaimSet in the above AuthorizationContext. This ClaimsIdentity instance will contain one claim for each claim in the claim set whose with right equals Rights.PossessProperty (this means that claims with right = Rights.Identity will not be reflected in Zermatt’s claims model).
  4. Creates one ClaimsPrincipal referring the above ClaimsIdentity collection.


Before returning, the property’s getter method also adds the created ClaimsPrincipal instance to the incoming message properties, so that subsequent calls will simply return this ClaimsPrincipal cached instance.

In other words, the IClaimsPrincipal returned by ClaimsPrincipal.Current represents a view, using the “new” Zermatt’s claims model, of the “old” (System.IdentityModel) claims model.

Note however that this IClaimsPrincipal must be explicitly requested and is not referenced by Thread.CurrentPrincipal neither by ServiceSecurityContext.PrimaryIdentity.



Authorization policies in WCF: from tokens to claim sets

In a previous post, I presented some classes for handling security tokens in WCF. This post describes the process that begins with the authentication of a token and ends with a collection of claim sets, available at the AuthorizationContext (see this previous post).

One of the classes referred in the last post is the SecurityTokenAuthenticator class, containing the following method

public ReadOnlyCollection<IAuthorizationPolicy> ValidateToken(
    SecurityToken token

This method “Authenticates the specified security token and returns the set of authorization policies for the security token

Surprisingly, this method does not return a set of claims. Instead it returns a collection of IAuthorizationPolicy.

What is an authorization policy?

An authorization policy defines a rule for adding claims to a claim evaluation context. More precisely, the IAuthorizationPolicy interface has an Evaluate method that receives an EvaluationContext.


This class represents the context on which the authorization policies are evaluated. It exposes a property with a read-only collection of claim sets – the claim sets previously added to the context – and a method to add claims sets to the context. So, an authentication policy, via the Evaluate method, conditionally adds claim sets into the context based on the claim sets already there. This conditional addition can be used to implement claim normalization or claim inference policies.

An example of claim normalization is a policy that adds the claim “Teacher of X” to the context if it contains the claims “Professor of X” or “Teaching Assistant of X”. In this case, normalization means to represent a set of syntactically different (but semantically equal claims) by only one claim.

An example of claim inference is a policy that adds the claim “Authorized to post CS101 grades” if the context already contains the claim “Teacher of CS101”.

Unconditional policies

A particular case of policy is the unconditional authorization policy, i. e., a policy that always add the same claims sets to the evaluation context, independently of the claim sets already there. These are the type of authorization policy typically returned by token authenticators.

Policy evaluation process

The policy evaluation process uses policies from two origins:

  • Policies resulting from token authentication. These policies represent the claims issued to the message originator.
  • External policies, representing additional policy rules (e.g. normalization and inference rules).


The claim sets resulting from the policy evaluation process are inserted into the AuthorizationContext.

Since there might be interdependencies between the policies, the policy evaluation process can call the Evaluate method of the same policy more than once. An example of interdependent policies is:

  • P1 (external policy): Add “Authorized to post CS101 grades” if “Teacher of CS101”.
  • P2 (external policy): Add “Teacher of CS101” if “Professor of CS101” or “Teaching Assistant of CS101”.
  • P3 (token policy): Add “Professor of CS101” unconditionally.

In this example, P2 must be evaluated after P3 adds the “Professor of CS101” claim, and P1 must be evaluated after P2 adds the “Teacher of CS101” claim. This results in more that one call to the Evaluate method, since there is no predefined order between the policies.

When a policy wants to be called again if additional claim sets are inserted by other policies, its Evaluate method must return false. If this method returns true, it means that no more claim sets will be added by the policy.

The policy evaluation process keeps repeatedly evaluating all the policies while

  • At least one policy returns false (meaning that it wants to be called again if new claim sets are added)
  • And the last policy evaluation cycle resulted in at least one new claim set added to the context.

If we model a authorization policy as a function mapping claim sets into claim sets, then the result of this evaluation process is the least fixed point of the policy set.

Security tokens in WCF

In WCF, security tokens are represented by classes derived from the SecurityToken abstract class. However, this class exposes little functionality:

  • A SecurityKeys property, to access the keys associated with this token.
  • Two properties, ValidFrom and ValidTo, with the token’s validity period.
  • A couple of methods for creating and matching key identifiers.

Most of the functionality related to security tokens is associated with three classes:

  • SecurityTokenProvider abstract class – Defines the interface for the creation of security tokens, i. e., for token factories. Typically, there is one concrete derived class for each token type (e. g. X509SecurityTokenProvider).
    Instances of classes derived from this one are used by the security protocol channel, at the message originator side, to create the tokens that are attached to the sent messages.


  • SecurityTokenSerializer abstract class – Defines the interface for serialization/deserialization into/from XML (XmlWriter/XmlReader) of token instances. The majority of token types are handled by the concrete WSSecurityTokenSerializer class.
    Instances with this type are used both at the message originator side and at the message recipient side.


  • SecurityTokenAuthenticator abstract class – Defines the interface for token verification and also for extracting the token’s claims. Typically, there is one concrete derived class for each token type (e. g. X509SecurityTokenAuthenticator).
    Instances with this type are used by the security protocol channel, at the message recipient side, to validate and extract the claims from the tokens attached to the received messages.

The figure below shows these classes, with some members hidden for legibility.



How are the provider/serializer/authenticator instances created?

The WCF runtime uses an object with type SecurityTokenManager (abstract class) to create a provider/serializer/authenticator instance, via the methods:

  • public abstract SecurityTokenProvider CreateSecurityTokenProvider(
        SecurityTokenRequirement tokenRequirement
  • public abstract SecurityTokenSerializer CreateSecurityTokenSerializer(
        SecurityTokenVersion version
  • public abstract SecurityTokenAuthenticator CreateSecurityTokenAuthenticator(
        SecurityTokenRequirement tokenRequirement,
        out SecurityTokenResolver outOfBandTokenResolver

How is the SecurityTokenManager instance created? 

Both the ClientCredentials and ServiceCredentials classes derives from the abstract class SecurityCredentialsManager, that contains a CreateSecurityTokenManager method.

Note that the ClientCredentials and ServiceCredentials classes hold the security configuration settings. These settings are reflected on the used token provider/serializer/authenticator via the chain of factories

  • ClientCredentials and ServiceCredentials creates SecurityTokenManager
  • SecurityTokenManager creates SecurityToken[Provider|Serializer|Authenticator]



Claims and claims sets in WCF

How are claims represented in WCF?

As described in an earlier post, the Identity Metasystem proposes a model where identities are defined by claim sets.

The WCF platform adopts this view and provides a claims-based authentication model, mostly defined in the System.IdentityModel.dll assembly, introduced with .NET 3.0.

In both the Identity Metasystem and the WS-* specifications, the claim concept is kept rather abstract.

The model defined by the System.IdentityModel assembly concretizes this concept through a class model presented in the next figure


A claim, represented by the Claim class, is defined as:

A claim is the expression of a right with respect to a particular value. A right could be read, write, or possess. A value could be a database, a file, a mailbox, or a property. Claims also have a claim type

The main properties of this class are

  • ClaimType, defining the type of the claim. For examples of claim types, see the ClaimTypes class.
  • Resource, defining the value of the claim.
  • Right, defining the right associated with the claim.

At first, I found this new definition hard to grasp and not completely in synch with the definition in the Identity Metasystem. However, in practice, the only used rights are:

  • PossessProperty – “specifies that the right represents a property that the entity associated with a claim possesses“, that is, the claim represents a property.
  • Identity – “specifies that the right represents an identity“. This right defines a property that uniquely identifies an entity.

What are claim sets?

Claims are grouped in claim sets, represented by the ClaimSet class. All the claims in a claim set must have the same issuer, which is recursively represented by a claim set (see the Issuer property of the ClaimSet class). This shouldn’t be a surprise, since in this model all identities are represented by claim sets.

How are claim sets accessible?

In WCF, the claim sets associated with a given context are accessible via an instance of AuthorizationContext, present as the a property of the current ServiceSecurityContext.

These claim sets are computed based on the security tokens attached to messages and also on external policies. The details of this process will be the subject of future posts.

WCF and the AsyncPattern property (part 3)

This is the third in a series of posts about the AsyncPattern in WCF.

The previous two posts described the purpose and usage of this property on the service side. The present post addresses the client side.

AsyncPattern at the client side

The AsyncPattern=true is used at the client side to expose an asynchronous programmatic interface to a service operation. Similarly to what happens at the service side, this property defines the local communication pattern between the service’s client code and the WCF runtime (at the client side).

Consider the following WSDL excerpt defining a portType with two request-response operations

   1: <wsdl:portType name="IService">
   3:   <wsdl:operation name="Operation1">
   4:     <wsdl:input wsaw:Action="..." message="..." /> 
   5:     <wsdl:output wsaw:Action="..." message="..." /> 
   6:   </wsdl:operation>
   8:   <wsdl:operation name="Operation2">
   9:     <wsdl:input wsaw:Action="..." message="..." /> 
  10:     <wsdl:output wsaw:Action="..." message="..." /> 
  11:   </wsdl:operation>
  13: </wsdl:portType>

By default, the interface generated by svcutil.exe has a synchronous interface

   1: public interface IService {
   3:     [System.ServiceModel.OperationContractAttribute(Action=".../Operation1", ReplyAction=".../Operation1Response")]
   4:     ReplyData Operation1(RequestData rd);
   6:     [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IService/Operation2", ReplyAction="http://tempuri.org/IService/Operation2Response")]
   7:     ReplyData Operation2(RequestData rd);
   9: }

However, using the /async switch, the svcutil.exe can also generate an interface with synchronous and asynchronous methods.

   1: public interface IService {
   3:     // Operation 1 synchronous method   
   4:     [System.ServiceModel.OperationContractAttribute(Action=".../Operation1", ReplyAction=".../Operation1Response")]
   5:     ReplyData Operation1(RequestData rd);
   7:     // Operation 1 asynchronous method pair         
   8:     [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action=".../Operation1", ReplyAction=".../Operation1Response")]
   9:     System.IAsyncResult BeginOperation1(RequestData rd, System.AsyncCallback callback, object asyncState);        
  10:     ReplyData EndOperation1(System.IAsyncResult result);
  12:     // Operation 2 synchronous method   
  13:     [System.ServiceModel.OperationContractAttribute(Action=".../Operation2", ReplyAction=".../Operation2Response")]
  14:     ReplyData Operation2(AsyncPattern.Client.AsyncClient.RequestData rd);
  16:     // Operation 2 asynchronous method pair         
  17:     [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action=".../Operation2", ReplyAction=".../Operation2Response")]
  18:     System.IAsyncResult BeginOperation2(RequestData rd, System.AsyncCallback callback, object asyncState);        
  19:     ReplyData EndOperation2(System.IAsyncResult result);
  21: }

Note that:

  • This setting does not change the communication pattern between the client and the service.
  • Using AsyncPattern=true at the client side is not in any way related to using AsyncPattern=true at the service side (the service doesn’t even have to implemented over WCF!)

AsyncPattern=true versus BeginInvoke

As stated here, using the delegate’s BeginInvoke method is not a way to achieve the same effect as AsyncPattern=true.


  • If the delegate target is a client channel instance (returned by a ChannelFactory), then the call will block (as described in a previous post).


  • If the delegate target is a “client proxy” (ClientBase derived class generated by svcutil.exe), then the call will not block. However a thread will remain blocked until the reply is received (the thread from the thread pool used to call the asynchronous method). This does not happens when using AsyncPattern=true, since the WCF supports full asynchronous requests.
    The blocking of this thread may not be significant on a smart client scenario. However, this “thread consumption” may be problematic on a middle-tier scenario, where a significant amount of requests may be pending at a given moment in time.

WCF and the AsyncPattern property (part 2)

This is the second in a series of posts about the AsyncPattern in WCF.

The previous post described the consequences of setting AsyncPattern = true on an OperationContractAttribute.

However, a question still remains: when and how to use AsyncPattern = true on the service-side?


  • The WCF documentation states that

Use an asynchronous approach in a service operation implementation if the operation service implementation makes a blocking call, such as doing I/O work. When you are in an asynchronous operation implementation, try to call asynchronous operations and methods to extend the asynchronous call path as far as possible

  • Similarly, Kenny Wolf (from the WCF/WF group) states that

If you have an operation that is blocking (accessing SQL, Channels, etc) then you should use AsyncPattern=true.  That way you’ll free up whatever thread we’re using to call your operation from

      and also that

If you aren’t doing something that’s “natively async”, then you shouldn’t be using AsyncPattern=true. That is, you shouldn’t just create a thread just for the sake of performing “background work” as part of an asynchronous operation

My conjecture is that asynchronous operation implementation should be used when there are conditions to release the calling thread, without requiring the creation of a new thread, and the time needed for the operation completion is significant. This happens when the operation performs “lengthy” IO requests. If the IO interface has an asynchronous interface, then the asynchronous operation call can be “linked” to the asynchronous IO call (see diagram below). Note that a service request is just a special kind of an IO request and that WCF also provides an asynchronous interface for clients.


The following sequence diagram shows the “linkage” between the asynchronous operation implementation and an asynchronous IO request.


  1. The WCF dispatcher calls the BeginOperation method, which in turn starts the asynchronous IO request (BeginIO) and returns immediately,. This sequence is done on an IO thread, which is “released” after BeginOperation returns.
  2. When the IO request is completed, the Operation Callback is called on an IO thread (not necessarily the same from the above sequence). This callback:
    1. Calls EndIO to finish the IO request and collects the IO result.
    2. Calls the WCF provided callback (passed as a parameter to BeginOperation).
    3. The WCF callback then calls EndOperation to finish the operation and collect the operation result.

Notice that the operation’s execution is divided into two sequences (two threads):

  • The “left-to-right” sequence processes the request, running on the IO thread associated with the service request.
  • The “right-to-left” sequence produces the reply, running on the IO thread associated with the IO request completion.

Namely there is no blocked thread between the start of the operation and the completion of the IO. This property is important in scenarios were there can be a significant amount of operations waiting for “lengthy” IO requests (e.g. middle-tier services).