More about WCF Binding configurations in STS scenarios

Some time ago I wrote an introductory post showing a basic architecture for a federation scenario in WCF. If we go back until then, the architecture showed there was something like the image below:

In this simple architecture we can find the following components:

  1. Client Application: The application that will be consuming the WCF services. In order to execute one of those services, this application needs first a security token granted by the STS.
  2. Security Token Service (STS): It is an specific service with the unique purpose to grant tokens according to some information received from the client. The process to grant tokens is not as easy as it sounds, I will talk more about this later in this post.
  3. Service: An specific service that provides some functionality required by the client application, for instance, a business operation. There is an implicit trust relationship between the service and the STS, any valid token granted by the STS can be used to authenticate the client.

Now that we have a better understanding of the overall architecture, I will discuss more in detail the WCF bindings involved in the process to interchange the messages between the different parties.

Communication between the client and the STS

At this point, a pair of RST/RSTR messages will be interchanged between both parties. The WCF infrastructure takes care of creating those messages for us, but we still need to configure some channel settings through a binding configuration. Some of those settings involve channel security, type of transport or more specific things like the type of security token that will be presented to the STS. 

As you can see, there is not any limitation here and we are free to use any of the existing WCF bindings.

In my previous sample I used a mutual certificate authentication over Http. Anyway, I could also use any transport or any other kind of token such as username token, a saml token, kerberos or any custom token.

  <binding name="MutalCertificateBinding">
    <security authenticationMode="MutualCertificate" 
         requireSecurityContextCancellation ="false"
         messageProtectionOrder ="SignBeforeEncrypt"

Communication between the client and the service

Here, we do not have the same flexibility as we had before, and WsHttpFederation is the only available binding.

As it name clearly says, this binding only supports the following aspects:

  • Authentication based on the token obtained from the configured STS
  • Http transport, which means that we can not use other kind of transport such as TCP, MSMQ or whatever we want.
  • Channel Security based on the token obtained from the STS.   

  <binding name="ServiceBinding">
    <security mode="Message">
      <message issuedTokenType="" negotiateServiceCredential="false">
      <issuer address="http://localhost/WCFSecurityTokenService/service.svc" bindingConfiguration="MutalCertificateBinding" binding="customBinding">
    <dns value="WCFQuickstartServer"/>

Other alternatives for the communication between the client and the STS

A typical case could be to present a token obtained from a second STS in our STS. This scenario is usually called Federation.

The image below illustrates the architecture for this kind of scenario:

What is really important about federation is that a trust relationship can be expanded across different domains without limits through different STS.

The WCF SDK already provides a good sample of this scenario, so you can find the code here [SDK Folder]\TechnologySamples\Scenario\Federation


  • Pablo,
    I've read several of your posting on this topic and I have a comment and question. We would prefer not to use the WSHttpFederationBinding in a scenario that is very close to a real STS scenario. In our case however, the STS is really always the iniital authenticating token provider, and will never be asked to trust a token from another source.

    For many reasons, we want to be able to use Tcp to communicate betwenn client and service, but use the STS like issued token model for communicating both authentication validation and claims.

    My question is, do I just need to create a custom binding based on Nettcp that includes the elements we need from the WSHttpFederated binding, and make sure both sides use it? I know I already have to create the custom token and manager and provider etc..., but I'm hoping the custom binding will be straight forward. Any insight or references would be appreciated.



  • Hi JF, I never tried to use a custom binding approach, but at first glance, it should work. I mean, a custom binding that uses the SAML token manager, provider and the TcpTransportBindingElement. You can find examples about this in the SDK, take a look to the SamlTokenProvider and CustomToken samples.


  • Can you give us a configuration sample which declares a custom binding that is similar to a wsFederationBinding

Comments have been disabled for this content.