Wednesday, December 30, 2009

Security Gotcha: Nonrepudiation


An important web services security requirement is nonrepudiation. This requirement prevents a party from denying it sent or received a message. The way to implement this is using Xml Digital Signatures. For example, if I sent a message which is signed with my private key, I cannot later deny that I sent it.

A common mistake is to think that every web service that require an X.509 certificate ensures nonrepudiation. This goes without say for web services that only require server certificate - in these services clients are either anonymous or username/password identified, which is considered weak cryptographically material.

However, also when a client X.509 is involved, nonrepudiation is not always guaranteed.
For example, let's examine a Wcf service which uses WsHttpBinding with TransportWithMessageCredential and clientCredentialType="Certificate":

   <binding name="WSHttpBinding_IService" >
     <security mode="TransportWithMessageCredential">
       <transport clientCredentialType="None" proxyCredentialType="None"
        realm="" />
       <message clientCredentialType="Certificate" negotiateServiceCredential="true"
        algorithmSuite="Default" establishSecurityContext="false" />

This is how the client request looks like:

<soap:Envelope xmlns:soap="" xmlns:xsi="" xmlns:xsd="" xmlns:wsa="">
   <To soap:mustUnderstand="1" u:Id="_1" xmlns="" xmlns:u=""></To>
   <o:Security soap:mustUnderstand="1" xmlns:o="">
    <u:Timestamp u:Id="_0" xmlns:u="">
    <o:BinarySecurityToken u:Id="uuid-b29856c4-1be8-4cf6-94ef-b3e2818b9924-1" ValueType="" xmlns:u="">...</o:BinarySecurityToken>
    <Signature xmlns="">
      <CanonicalizationMethod Algorithm="" />
      <SignatureMethod Algorithm="" />
      <Reference URI="#_0">
        <Transform Algorithm="" />
       <DigestMethod Algorithm="" />
      <Reference URI="#_1">
        <Transform Algorithm="" />
       <DigestMethod Algorithm="" />
       <o:Reference URI="#uuid-b29856c4-1be8-4cf6-94ef-b3e2818b9924-1" />
   <EchoString xmlns="">

The message body is not signed!
This practically means anyone who has this message (for example the server) can extract the signed parts and resend them with a bogus body.


What's next? get this blog rss updates or register for mail updates!

Saturday, December 26, 2009

When your unit test is not implemented...


When your unit test is not implemented yet you want to make sure everybody knows about it. One bad way is to throw an exception in the test first line:

public void MyNewTest()
   throw new NotImplementedException();

The reason is that when you see in the report this failure you can never tell if the error comes from the unit test or the application under test...

The good solution is to use a build in feature of your unit test framework. For example, the Ignore attribute in NUnit. If for some reason you have to throw an exception (so the test will be red) at least throw some better error class like "new UnitTestNotImplementedException()".


What's next? get this blog rss updates or register for mail updates!

Unit Test Legitimic Failures


Our unit tests are expected to pass every time. When they fail we are expected to fix the regression. But in some cases it is ok for a test to temporarily not pass. For example, if the test is a small regression in a minor feature and we are currently employed with other critical missions. But while the test is failing we should at least make sure it will not cause any noise like spamming out the team.

When we use NUnit, the solution is the Ignore attribute:

public void SomeTest()

The test is not red any more:


What's next? get this blog rss updates or register for mail updates!

The XmlReader state should be Interactive


Recently I was parsing Xml in c# from an XmlReader to an XElement:

MemoryStream m = GetMemoryStream();
XmlReader r = XmlReader.Create(m);
XElement e = XElement.ReadFrom(r) as XElement;

The last line threw this exception:

The XmlReader state should be Interactive.

In MSDN ReadState.Interactive state is described as:

The Read method has been called. Additional methods may be called on the reader.

But why should I call read? It is the XElement responsibility to do it.

The solution is pretty simple though:

MemoryStream m = GetMemoryStream();
XmlReader r = XmlReader.Create(m);
//This is how we make the XmlReader interactive

XElement e = XElement.ReadFrom(r) as XElement;


What's next? get this blog rss updates or register for mail updates!

Wednesday, December 9, 2009

Not all errors are red


Here's some WCF service trace log. Is there a problem with the service the log belongs too?

Of course, we see an error in the red line.

What about this service?

Well, nothing red here. Let's drill down into the "warning" details:

It seems WCF errors come in more than one color.


What's next? get this blog rss updates or register for mail updates!

Friday, November 20, 2009

Axis 2 WS-Security (rampart) FAQ


Rampart is the WS-Security module of Axis2.
Prabath summarizes all the current posts that were published in the rampart FAQ blog.


What's next? get this blog rss updates or register for mail updates!

Thursday, November 19, 2009

Generating meaningful names from a url


A common programming task is to extract some meaningful name from a url.
One example is saving the contents of a url to a file name on disk - we need to have the name for the file.
Bellow there is a c# method that I have written that extracts this name + the results it produces on a few urls. - Sanity - Sanity - Sanity1234567890123456789012345678901234567 - Sanity - Sanity - Sanity - Sanity_wsdl - Sanity

public static string GetSuggestedNameFromUrl(string url, string defaultValue)
  const int MaxChars = 50;

  string res = Path.GetFileNameWithoutExtension(url);

  //check if there is no file name, i.e. just folder name + query string
  if (String.IsNullOrEmpty(res) || IsNameOnlyQueryString(res))
    res = Path.GetDirectoryName(url);
    res = Path.GetFileName(res);

    if (String.IsNullOrEmpty(res))
       res = defaultValue;

  res = ReplaceInvalidCharacters(res);

  if (res.Length > MaxChars)
     res = res.Substring(0, MaxChars);

  return res;

private static string ReplaceInvalidCharacters(string res)
  return Regex.Replace(res, @"[^\w]", "_", RegexOptions.Singleline);

private static bool IsNameOnlyQueryString(string res)
  return !String.IsNullOrEmpty(res) && res[0]=='?';


What's next? get this blog rss updates or register for mail updates!

Saturday, August 22, 2009

BindingBox: Convert WCF Bindings


The WCF BindingBox is here!

What is it?
BindingBox is an online application that converts WCF bindings to a customBinding configuration.

Why we need it?
WCF bindings capture a general use case and allow us to customize it. For example, basicHttpBinding is good for interoperability with older soap stacks while WSHttpBinding fits WS-* based communication. However, there are cases where we can not use the out of the box bindings. For example:

  • We want to further customize the binding behind what it exposes. For example, we might want WSHttpBinding not to send a timestamp (for interoperability reasons) but this is not a built in option.

  • We have a special use case which is not captured by any of the out-of-the-box bindings. For example, we want to use binary encoding over http.

    In such cases we need to convert our binding into a custom binding. This is not a trivial process. In particular, some security settings can be very frustrating to translate.

    For this reason I have written the WCF BindingBox. This is an online application which automatically converts any binding to a customBinding.

    How to use it - Tutorial

    Step 1 - Get your current binding

    Just open your web.config or app.config file and navigate to the "<bindings>" element. Then copy its content to the clipboard. Be sure to copy the wrapping "<bindings>" element as well:

         <binding name="MyBinding">
            <message clientCredentialType="UserName" />

    Step 2 - Convert your binding

    Just navigate to the BindingBox and paste your binding from step 1. Then click on the "Convert to CustomBinding" button and copy to the clipboard your new binding. It may look like this:

       <binding name="NewBinding0">
         <transactionFlow />
         <security authenticationMode="SecureConversation" messageSecurityVersion="WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10">
           <secureConversationBootstrap authenticationMode="UserNameForSslNegotiated" messageSecurityVersion="WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10" />
         <textMessageEncoding />
         <httpTransport />

    Step 3 - Use the custom binding

    Basically, you now just need to use the BindingBox result as your binding configuration.

    In practice you would do it in one of the following ways:

  • In your .config file manually configure your endpoint to use a custom binding and set its configuration.
  • Use the WCF configuration editor to configure your endpoint to use a CustomBinding. then in your .config override the default customBinding configuraiton with the BindingBox result.

    Currently supported bindings

    BindingBox currently supports these bindings:

  • WSHttpBinding
  • WS2007HttpBinding
  • BasicHttpBinding

    More to follow

    Stay tuned for these:

  • NetTcpBinding
  • NetNamedPipeBinding
  • WSFederationHttpBinding
  • WS2007FederationHttpBinding

    Known issues

  • DefaultAlgorithmSuite is not converted
  • ReaderQuotas are not converted

    Please report any bug you find. Also feel free to submit an enhancement request.

    There is also a nice story behind BindingBox: It uses cutting edge technologies such as Windows Azure and MEF. More to come on this...


    What's next? get this blog rss updates or register for mail updates!
  • Tuesday, July 28, 2009

    Debugging WCF


    j_saremi has posted a message in the WCF forum noticing that WCF source code can now be downloaded from Microsoft. The source can be viewed using the reflector since ever - no news here - but now it can actually be used to debug!

    Really, see:


    What's next? get this blog rss updates or register for mail updates!

    Cryptic WCF error messages (part 6 of N)


    If you have followed the previous parts of this series you already know it tries to diminish the mystery of WCF errors.

    When X.509 certificates are used you might get this error:

    The certificate 'CN=localhost' must have a private key that is capable of key exchange. The process must have access rights for the private key.

    The second part of the error implies that you may need to set permissions on the private key. I'll deal with that in a separate post.

    The first part of the error means that the certificate was created with a private key that is not capable of key exchange. This can happen when you use makecert.exe to create a test certificate without specifying the correct flags. The correct way to use makecert is:

    makecert -ss My -pe -n "CN=localhost" -sky exchange


    What's next? get this blog rss updates or register for mail updates!

    Saturday, July 25, 2009

    log4net gotcha: AppDomains


    We are using the log4net logging framework in a new project.
    In one initialization point of the application we init it:

    using log4net;
    using log4net.Config;

    XmlConfigurator.Configure(new FileInfo("log4net.config"));

    And in many other locations we use it:

    ILog log = LogManager.GetLogger(typeof(SomeClass));
    log.Debug("some debugging message");

    In one of my classes the messages I've logged did not appear in the log file (or in any of the other appenders). When I explicitly re-initialized log4net in the same class the messages were written successfully. A short investigation found the reason: This class is called from a different AppDomain than the other classes. log4net's LogManager class is static, which limits its scope to the calling AppDomain.

    Conclusion: log4net needs to be initialized once per AppDomain.


    What's next? get this blog rss updates or register for mail updates!

    Why lawyers make more money than programmers


    Recently I have checked the possibility to bring Microsoft's Web Services Enhancements (WSE) 3.0 in the installation of a product I author. I already know that Microsoft products cannot be dispatched as is and I need a special redistributable version. Luckily, WSE3 has a Redistributable Runtime MSI.

    So I run this msi and the first stage in the installation wizard is the end user license agreement (EULA). Now I'm not a legalist but the beginning looks promising:

    These license terms are an agreement between Microsoft Corporation...and you. You may install and use one copy of the software on your device...

    "Microsoft...and you" sounds good, and "you may install" is what I wanted to hear anyway. But the second item is suspicious:

    You may not
  • work around any technical limitations in the software;

  • reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation;

  • make more copies of the software than specified in this agreement or allowed by applicable law, despite this limitation;

  • publish the software for others to copy;

  • rent, lease or lend the software;

  • transfer the software or this agreement to any third party; or

  • use the software for commercial software hosting services.

  • Now wait one second. If I may not transfer the software to any third party, then how can I redistribute this Redistributable Runtime MSI? Or is this EULA just an agreement between Microsoft and the third party, in which case where is the agreement between Microsoft and me? Am I not worth at least one or two vague terms?

    Anyway I passed this to our legal department. I better go work on some legacy code, which comparing to this looks more readable than ever...


    What's next? get this blog rss updates or register for mail updates!

    Friday, July 3, 2009

    Security in SOA


    Prabath gave a great presentation on SOA & web services security in the WSO2 summer school. It is particularily interesting for everyone who wants to understand what stands behind security related WS-* standards such as WS-Security and WS-Trust.


    What's next? get this blog rss updates or register for mail updates!

    Sunday, June 28, 2009

    Test Drive in Skydrive


    This one is for the bloggers among my readers but actually everyone can find it useful.

    You might have noticed recently how downloadable items in my blog appear. For example here is my unit tests presentation:

    My file storage service is microsoft's Skydrive. Basically you can upload there any file you want and share it with everyone. This is a free service.

    Generally I'm happy with it but here are some points to improve:

  • There is no direct link for download - users need to enter the "windows live" portal and download from there. I guess there is a traffic reason for this. But there may be alternatives, like having the link embedded in the consuming site with some logo/link to msn. Update: Tim Acheson has created an API to get the direct link.

  • The download link in the live spaces portal is not explicit enough. Yes, the file is just one click away, but the image does not look clickable enough and the "download" link is pale:

  • No statistics such as "how many users downloaded this file". Very important, in particular to bloggers.

  • The embedded files do not appear in feed readers (since they use IFrame):



  • If you will surf to

    before you'll notice it you'll be in

    which makes it hard to add skydrive to the browser favorites.

    I know some Microsoft employees read my blog so hopefully these issues will be resolved in a future release ;-)


    What's next? get this blog rss updates or register for mail updates!
  • Saturday, June 27, 2009

    Contract-First vs.Code-First, Still?


    Yes, an old debate.

    However it is interesting to see how it is still relevant even a few years later when new frameworks are around.

    The two common paradigms for building a web service are code-first and contract-first. The former means you start writing your c#/java/whatever service code and generate the contract (wsdl) from it. The latter means you first create the wsdl (either manually or using some tool) and then create the service code from it.

    So with code-first you write this:

    public string HelloWorld() {
       return "Hello World";

    And this is auto generated for you:

    <s:schema elementFormDefault="qualified" targetNamespace="">
       <s:element name="HelloWorld">
         <s:complexType />
       <s:element name="HelloWorldResponse">
             <s:element minOccurs="0" maxOccurs="1" name="HelloWorldResult" type="s:string" />

    While in contract-first you write the wsdl (possibly using a tool) and the code is generated.

    Pros for code-first:

  • Developers are already familiar with code so development is faster. Being veteran developers, architects are also code-savvy.
  • More online resources
  • You'll need to use it anyway

    Pros for contract first:

  • Better interoperability
  • Defers implementaiton details
  • You'll need to use it anyway

    Code first is the de-facto "default setting" in almost all frameworks - most tutorials and documentation use it. So contract-first is much more interesting from a "let's write an interesting post" POV.

    In the next series of posts I'll write on the contract-first approach using several frameworks.

    My opinion on the matter is that it does not really matter. Contract-first is important from the interoperability perspective, but most frameworks do not support all wsdl/schema artifacts. So ignoring the code you'll find yourself working with a perfectly interoperable wsdl that no framework can consume. For example xsd:union is not supported in .Net and xsd:choice isn't in Axis2 1.3. Contract without an implementation is useless.

    On the other hand, code-first also requires you to look in the generated wsdl and verify it is interoperable. A service that can't be consumed is also useless.

    So code-first or contract-first? Whatever, you'll need to do both anyway.


    What's next? get this blog rss updates or register for mail updates!
  • Friday, June 26, 2009

    WCF proxy cleanup


    When working with a WCF client proxy we need to close it after usage.
    Failing to do so would of course affect our client performance. However it would also affect our server performance and in some cases might block new client from connecting to it. One example is when using sessions (which is the default wcf behavior): Since the open sessions number is limited a non-closed client might block a new client.

    However the simple way of closing a client:


    is naive. The close may fail, for example due to the client not being able to release the session because of a server problem. For this reason we need to catch any possible exception.

    Pablo perfectly explains how to do it.


    What's next? get this blog rss updates or register for mail updates!

    Thursday, June 25, 2009

    Unit Tests Presentation


    Yesterday I have conducted a session on Unit Testing.
    My presentation answers the most common questions on the matter:

  • What to test?
  • When to test?
  • How to write a good unit test?

    And most important the presentation is full of examples.

    Download it from here

    Feel free to use it or present it whether you are a developer, a tester or a TDD evangelist.


    What's next? get this blog rss updates or register for mail updates!
  • Monday, June 22, 2009

    WSE2 With Visual Studio 2005, Anyone?


    I've just published a post on how to use WSE3 with Visual Studio 2008.
    I forgot to mention that the same technique can be used to have WSE2 and VS 2005 (or even VS 2008) working together.


    What's next? get this blog rss updates or register for mail updates!

    WSE3 is so... VS 2008


    Microsoft has provided WSE3 a Visual Studio 2005 add-in with nice UI support. Look how nice it is:

    The less nice part is that there is no such support for Visual Studio 2008 as Microsoft is encouraging us to use WCF instead. Which is a good idea generally, but not alway feasible: The reality is that a lot of the WSE3 & VS 2005 projects were migrated to VS2008 and lack this fundemental support. Also a lot of new projects need compatability with WSE3 which is not always possible with WCF.

    So how WSE3 can work with VS2008?

    The truth is that the WSE run time is agnostic to the IDE version. IOW projects built with VS 2008 can use WSE3 in run time in the same way as VS 2005 projects. This means we are left with the tiny mission of actually developing these projects. Well, not so tiny but also not too hard. We have two options for our needs:

    Option 1 - Trainer Wheels

    We need to remember that configuring WSE infrastructure is mostly a one-time mission - we do not frequently alter it during development. So we can create a VS2005 project with WSE3 and migrate it to VS2008 as is using the VS migration wizard. Usually we would never need to look at the WSE configuration until late stages. Then we can open our VS2005 project, change what we want from UI, and notice that such changes only affect this section of our web.config/app.config:


    So we can copy&paste this part to our new project. In case we use a .policy file we can copy all of its contents to the new project. If this looks lame it's only because VS 2005 is strictly a trainer wheel here, we do not actually need it. For this we have:

    Option 2 - Just 2008, Please

    We can directly use WSE3 with VS2008 in the following way:

    1. In our project, add assembly reference to "Microsoft.Web.Services3.dll" (it's in the GAC and also in %Program Files%\Microsoft WSE\v3.0)

    2. If we are creating the client side we would like to use "add web reference". This is not available but luckily we have the option to use %Program Files%\Microsoft WSE\v3.0\Tools\WseWsdl3.exe:

    WseWsdl3.exe http://some.vendor/service.asmx?wsdl

    This will create our proxy .cs file which we can add to our project. The file looks like this:

    public partial class OurServiceName : Microsoft.Web.Services3.Messaging.SoapClient

    So in our code we can create a new instance of this class and call the service:

    OurServiceName proxy = new OurServiceName();

    For the service side we can just create a new normal web service project, nothing special.

    3. We can now use the WseConfigEditor3.exe tool that comes with the WSE3 SDK to edit our app.config/web.config and even add a policy file. Then in our client code we can tell the proxy to use this policy:


    This is the same we would do with VS 2005 so no news here.

    If we are on the server side we need to check both "Enable this project for Web Services Enhancements" and "Enable Microsoft Web Services Enhancements Soap Protocol Factory" in the configuration editor:

    Pretty easy after all...


    What's next? get this blog rss updates or register for mail updates!

    Saturday, June 20, 2009

    Are WCF defaults considered harmful?


    When we programmers see such an error message

    quota 65536 too small please increase

    or something along these lines, and have no idea what this quota is good for, we face the temptation to put there a ridiculously large number (like 6.10* 8^23) so we would never have to it again. We should hold ourselves from doing this and put a rational number based on our needs. See the story bellow.

    Ayende published an interesting post on a case where he needed to send a large number of objects between a WCF client and server. For this he had to alter some server-side default:

    [ServiceBehavior(MaxItemsInObjectGraph = Int32.MaxValue)]

    When he "update service reference" on his client he found out that this setting is not propagated to the clients which forces him to manually change this setting in each and every client (as stated in MSDN).

    Arnon follows this up in his post and claims the following:

  • This setting needs to be automatically propagated to clients
  • There are other settings which are not propagated and needs to be, for example message size limits
  • The default setting should be higher (although not infinite)

    I absolutely agree with the first claim. This setting is in effect both when sending and receiving data. Since in each call one party sends and another receives this setting has to be correlated between the parties. The way to dispatch this setting to clients would probably by extending the wsdl's WS-Policy with this new setting (which would be msn proprietary for that matter).

    I only partially agree with Arnon's second statement. The MaxReceivedMessageSize setting (if it's the one he refers to) only affects the receiving side. There is no limit on the size of outgoing messages. Here it makes sense to have a different value for the client and the server since they probably have different capabilities in terms of hardware and they also need to handle different data.

    Going back to the opening paragraph, I want to make clear the rational behind all of these settings (and me and Arnon are probably in agreement on this). These settings are not meant to directly improve the performance of the service but rather they aim to block DOS attacks. So if the limit on this setting is too high an attacker can send an XML bomb which will consume large server resources. These settings are much more important for the server then for the client, but as long as clients allow to customize them the client values do not always have to be correlated with the server ones.


    What's next? get this blog rss updates or register for mail updates!
  • Friday, June 19, 2009

    WCF Self Hosting Project Template


    Visual Studio 2008 comes with project templates for a WCF web site and a WCF service library. But what about self hosting?

    I've create a simple self hosting template which you can use when starting new projects. This is useful for real projects as well as for quick POC/prototyping projects. For the latter it brings the following advantages over the out of the box templates:

  • It encapsulates the service as an executable so it can be easily deployed without messing with IIS (xcopy is enough)
  • It enables to use transports which are not supported in web sites (e.g. netTcp).


    1. Save this template

    (if you do not see the file use this direct link)

    in this location:

    %My Documents%\Visual Studio 2008\Templates\ProjectTemplates\Visual C#\WCF

    Note 1: save the zip file itself, no need to extract it
    Note 2: If the WCF subfolder does not exist then create it

    2. The template now appears in VS "new project" window under the Visual C# \ WCF node.

    3. After you create the project press F5 to run it - all the information you need to know is printed to the console.

    Enjoy :)


    What's next? get this blog rss updates or register for mail updates!
  • Thursday, April 30, 2009

    Introducing WCF ClearUsernameBinding


    : ClearUsernameBinding is now hosted on GitHub. This post contains the updated usage instructions.

    Using cleartext username/password is usually not recommended. However it is sometimes required (like with F5's BIG-IP). WCF does not natively allow us to use such scenario. For this reason I have written ClearUsernameBinding - a WCF binding that enables to send cleartext username/password over HTTP.

    Full source code is available in google code github.

    So without any further preparations let's see how to use ClearUsernameBinding.

    Step 1: Download latest release
    Download it here or go to google code github.
    Then extract the zip to some folder, let's say C:\program files\ (the ClearUsernameBinding subfolder will be created when extracting the zip).

    Step 2 (optional) - Run the sample project
    It can be useful to run the sample application.

    Run the server:

    C:\program files\ClearUsernameBinding\TestService\bin\Release\

    And now the client:

    C:\program files\ClearUsernameBinding\TestClient\bin\Release\

    And if everything went smoothly you have just seen ClearUsernameBinding in first action!

    Step 3 (optional) - Investigate the sample project source code
    The best way to learn a new (and very simple in this case) technology is by looking at existing projects. Just open with VS 2008 the solution file:

    C:\program files\ClearUsernameBinding\ClearUsernameBinding.sln

    And look at the source of the projects TestClient and TestService. These two projects are just normal WCF projects configured to use ClearUsernameBinding. In other words, making a WCF client/service use ClearUsernameBinding is just a matter of changing web.config and does not require coding. We will see in the next steps how to do it from scratch.

    I'll probably have a separate post on the binding implementation itself. It is pretty straight forward and the handling of security is as I learned from Nicholas Allen's blog.

    Step 4 - Creating your own service
    For this step just create any normal WCF web site or a self hosted service.

    Step 5 - Configure the service to use ClearUsernameBinding
    Add your project a dll reference to

    C:\Program Files\ClearUsernameBinding\ClearUserPassBinding\bin\

    Then open web.config and register the ClearUsernameBinding under the system.ServiceModel section:

       <add name="clearUsernameBinding" type="WebServices20.BindingExtenions
    .ClearUsernameCollectionElement, ClearUsernameBinding" />

       <binding name="myClearUsernameBinding"

    Finally configure your endpoint to use ClearUsernameBinging and its configuration:

    <endpoint binding="clearUsernameBinding" bindingConfiguration="myClearUsernameBinding"
    contract="WebServices20.SampleService.IEchoService" />

    An example of the complete web.config is inside the full project binary&source in

    C:\Program Files\ClearUsernameBinding\TestService\bin\Release\

    Step 6 (optional) - Configure the message version
    If you need to use a specific message version configure it in the "messageVersion" attribute in the above configuration. Valid values are: Soap11WSAddressing10, Soap12WSAddressing10, Soap11WSAddressingAugust2004, Soap12WSAddressingAugust2004, Soap11, Soap12, None, Default.


    <binding name="myClearUsernameBinding" messageVersion="Soap12">

    Step 7 - Configure the username authentication
    This one needs to be done in any username/password authenticated service and not just one that uses ClearUsernameBinding. By default your server will authenticate the users against your active directory domain. If you want to do your own custom authentication you need to create a new class library project with a class that implements System.IdentityModel.Selectors.UserNamePasswordValidator

    The class can look like this:

    public class MyUserNameValidator : UserNamePasswordValidator
      public override void Validate(string userName, string password)
       if (userName != "yaron")
        throw new SecurityTokenException("Unknown Username or Password");

    Don't forget to add dll reference to System.IdentityModel and System.IdentityModel.Selectors or the project will not compile. Then add this project as a project reference to your service project/website and configure the latter to use this custom authenticator:

       <behavior name="SampleServiceBehaviour">
        <userNameAuthentication     userNamePasswordValidationMode="Custom"
    "WebServices20.Validators.MyUserNameValidator, MyUserNameValidator" />
    <service behaviorConfiguration="SampleServiceBehaviour" name="WebServices20.SampleService.EchoService">

    Again the full sample is available for download.

    Step 8 - Run the service
    Yes, the service is now ready to be activated, so run it when you are ready (run it directly from VS, just press F5).

    Step 9 -Build a client
    A service is worth nothing if there are no clients to consume it.
    Create a new console application.
    Right click the "References" node in the solution explorer and choose "Add service reference". Specify the WSDL of the server. If you are running the server from the given sample then the wsdl is in http://localhost:8087/SampleService/?WSDL. If you used your own server just run it and get the wsdl.

    Now add some client code that uses the proxy to call the service. Don't forget to specify your username/password. For example:

    ServiceReference1.EchoServiceClient client = new TestClient.ServiceReference1.EchoServiceClient();
    client.ClientCredentials.UserName.UserName = "yaron";
    client.ClientCredentials.UserName.Password = "1234";

    Step 10 - Configure the client
    Configuring the client is as simple as configuring the service.
    Here is the full client app.config:

       <endpoint address="http://localhost.:8087/SampleService/" binding="clearUsernameBinding"
       bindingConfiguration="myClearUsernameBinding"   contract="ServiceReference1.IEchoService"
       name="ClearUsernameBinding_IEchoService" />

        <add name="clearUsernameBinding"    type="WebServices20.BindingExtenions
    .ClearUsernameCollectionElement   , ClearUsernameBinding" />

        <binding name="myClearUsernameBinding"



    Step 11 - Done, Done, Done!
    That's all. You can now run your client and see how WCF can be used to access a service with a cleartext username/password. Use a tool like fiddler to verify that indeed a clear username is sent (I've shorten some low-level stuff from bellow message):

       <EchoString xmlns="">

    Sending username/password on the clear is not available out of the box with WCF (for reasons mentioned above). If such a scenario is required then ClearUsernameBinding needs to be used.


    What's next? get this blog rss updates or register for mail updates!

    Wednesday, April 29, 2009

    Interoperability Gotcha: Visual Studio 2008 Proxy Flavours


    The following interoperability issue can happen with a .Net 3.5 clients and older web services from various platforms (including Java. and .Net)

    Everyone knows that Visual Studio 2008 has a build-in support for WCF which is the latest generation of Microsoft soap stack. By default, when writing web service clients in VS 2008 a WCF-flavored proxy is generated. However WCF only supports a subset of XML schema and WSDL patterns. For example it does not support RPC/Encoded WSDLs and XML attributes. Many older WSDLs use RPC/Encoded. With such WSDLs WCF is supposed to gracefully downgrade itself to .Net 2.0 which does support these WSDLs. I have noticed that in some cases this does not happen correctly. The result can be web service methods returning null instead of values.

    The solution for such cases is to manually instruct VS 2008 to use its backward compatible proxy. All you need to do is:

    1. Press the "Add Service Reference" as usual

    2. Press the "Advanced..." button

    3. Select "Add Web Reference..."

    4. Use the good old .Net 2.0 proxy flavours


    What's next? get this blog rss updates or register for mail updates!

    Sunday, April 26, 2009

    Java, WCF & Web Services Interoperability (part 2 of N): Know your X.509


    So, you want to write an Axis2 web service and have .Net WCF clients too? Or maybe you already have a .Net 2.0 endpoint and want it to be consumed by WSIT? Yes, that’s possible, but there is some important stuff you should know about. Whether you are a .Net WCF, AXIS2, Metro or any other framework developer/tester – you want to stay tuned for this series.

    When a Java client sends a request to a secured WCF service sometimes this soap fault can come back:

    An error occurred when verifying security for the message

    Insdie the WCF trace log these errors appear:

    Message security verification failed.

    And the inner exception is:

    Cannot read the token from the 'BinarySecurityToken' element with the '' namespace for BinarySecretSecurityToken, with a '' ValueType. If this element is expected to be valid, ensure that security is configured to consume tokens with the name, namespace and value type specified.

    The problem is with the X.509 certificate/key that the client is using: It is of version 1 of X.509. WCF only supports version 3 certificates. We can see that the request strictly stated it was using v1:

    <o:BinarySecurityToken u:Id="uuid-856599a5-7c38-465c-9ae8-69b59af419b7-1" ValueType="" xmlns:u="">MIIBxDCCAW6gA…

    Interestingly enough, Wcf can work with the certificate content itself so if we could change the SOAP to have “v3” instead of “v1” everything would have worked. However the straight forward way to solve this is to use X.509V3 at the client side.
    BTW We can see the certificate version by double clicking its file in windows:


    What's next? get this blog rss updates or register for mail updates!

    Saturday, April 18, 2009

    WCF Performance: Making your service run 3 times faster


    A lot of people use WCF default settings on production. In many cases changing these defaults can gear up the service throughput dramatically.

    Let's look at the following use case:

  • WsHttpBinding is used

  • Message level security is used: X.509 certificate or windows authentication, where client can also use a username/password or be anonymous

  • (Optional assumption) A typical client makes one service call and then disconnects

  • The WsHttpBinding implicit defaults can be explicitly written as bellow:

      <binding name="BadPerformanceBinding">
       <security mode="Message">
        <message clientCredentialType="..."
         establishSecurityContext="true" />

    Let's simulate a load on this service by employing many virtual users who constantly call the service one time and immediately disconnect. The number of users should be large enough such that service will use its max capacity. The results are:

    Transactions per second: 15.235
    Average time of a transaction: 1.4 seconds

    Note: I didn't use a super strong server here but as we can see below it shouldn't matter for our needs. Also a load of just a few minutes was enough to prove our theory.

    Those are not very good results of course.

    Now let's tweak the configuration a little bit:

      <binding name="BetterPerformanceBinding">
       <security mode="Message">
        <message clientCredentialType="..."
         establishSecurityContext="false" />

    And with the same amount of virtual users we get these results:

    Transactions per second: 51.833
    Average time of a transaction: 0.384 seconds

    That's 3.5 times faster!

    So, what happened here?
    Since the only change we did is in two settings we need to analyze each of them.

    This setting determines whether the clients can get the service credential (e.g. certificate) using negotiation with the service. The credentials are used in order to authenticate the service and to protect (encrypt) the messages. When this setting is set to "true" a bunch of infrastructure soap envelopes are sent on the wire before the client sends its request. When set to "false" the client needs to have the service credentials out of band.

    The trade off here is better performance (using "false") versus more convenience (using "true"). Setting "false" has its hassles as we now need to propagate the service credential to clients. However, performance wise, setting "negotiateServiceCredential" to "false" is always better.

    Take a look at how many infrastructure messages are exchanged when negotiateServiceCredential is "true":

    While when not negotiating life is much brighter:

    This setting determines whether WS-SecureConversation sessions are established between the client and the server. So what is a secure conversation anyway? In a very simplified manner we can say that a normal secured web service request requires one asymmetric encryption. Respectively, normal N requests require N asymmetric encryptions. Since asymmetric encryption is very slow, setting up a secure conversation is usually a good practice: It requires a one-time asymmetric encrypted message exchange in order to set up a session; Further calls in the session use symmetric encryption which is much faster.

    Now remember that in our case we assume that clients call the service just one time and disconnect. If a secure session is established the message exchange will look like this:

    Message 1: Setting up a secure session (asymmetric encryption)
    Message 2: The actual request (symmetric encryption)

    If we do not use secure session we have:

    Message 1: The actual request (asymmetric encryption)

    So it is clear that we're better off in the latter case.

    With secure sessions there isn't really any trade off and the decision is quite scientific: When only one client request is expected set establishSecurityContext to "false".

    Wisely changing WCF defaults can yield a significant improvement in your service performance. The exact changes need to be made and their exact effect are dependent in the scenario. The example above showed how to speed up a certain service 3 times faster.


    What's next? get this blog rss updates or register for mail updates!

    Wednesday, April 15, 2009

    WCF Gotcha: Disabling SSL Validation


    When you use SSL with WCF or .Net 2.0 web services you might get this exception:


    Could not establish trust relationship for the SSL/TLS secure channel with authority 'localhost'.

    This means that the X.509 certificate that the server presented is not valid according to your client's trust chain. the trust chain is the list of certificate issuers that you trust. In many cases this means you should not trust this web service. In some cases you decide to trust it anyway, due to the fact that you know the author or are still in early testing stages. You have two options:

    Option 1 - Make the certificate valid
    You would need to have the server certificate or its issuer's certificate in the trusted certificates store of your client. This can be done using WinHttpCertCfg.exe or using the "mmc" console.

    Option 2 - Configure WCF/.Net 2.0 to not validate the certificate
    With WCF, a common gotcha is to try and achieve that by setting:

    <authentication certificateValidationMode="None" />

    However this will not work with transport level security (SSL) but only with message level security. The correct way to do it is the same one as with .Net 2.0 web services. Just add this code before calling the service:

    using System.Net;
    using System.Net.Security;
    using System.Security.Cryptography.X509Certificates;
    ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(OnValidationCallback);
    public static bool OnValidationCallback(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors errors)
    return true;


    What's next? get this blog rss updates or register for mail updates!

    Tuesday, April 7, 2009

    Who Moved My Service Reference?


    When you use Visual Studio to add a Service Reference (VS 2008) or a Web Reference (VS 2005) to a web service you do not see the generated proxy immediately. One reason can be that th proxy was not generated due to errors and in this case VS notifies you in the "Error List" pane. If import was successful you can see the generated code by clicking the "Show All Files" option (see images).



    BTW most of the time you don't really need to look inside the proxy - you can just use it.


    What's next? get this blog rss updates or register for mail updates!

    Sunday, April 5, 2009

    Web Service Attachments Support Matrix


    Many web services require sending or receiving large files. There is an interesting evolution of attachments standards - however today MTOM is the preferred way to do this. Nevertheless not all SOAP stacks support MTOM and in addition some existing services might already employ older techniques. These techniques may include Soap With Attachments (SwA) or WSI attachment profile (SwaRef) MIME attachments or DIME. I have investigated the attachments support of a few known soap stacks: .Net WSE2 & WSE3, WCF, Axis, Axis2, Metro (WSIT), CXF (XFire), gSOAP, SpringWS and JBossWS. The bellow table summarizes the web service attachments support matrix (click to enlarge):

    Note: Some of this information I took from the providers web sites which did not always supplied a nice sheet with the list of supported standards. You are encouraged to correct me if I made a mistake.

    The conclusion is as expected: MTOM should be used for new web services; If you know you’ll never have .Net clients then you can also use Soap With Attachments (SwA) or WSI attachment profile (SwaRef) MIME attachments; Beware of DIME if you care for I14Y.


    What's next? get this blog rss updates or register for mail updates!

    Friday, March 27, 2009

    WCF CustomBinding Equivalent to WSHttpBinding


    It is sometimes useful to build a WCF CustomBinding equivalent to some other binding. This allows a richer set of customizations. Here is the CustomBinding equivalent to the WSHttpBinding defaults (windows authentication):

    Update: Convert bindings automatically using the WCF BindingBox.

       <binding name="MyBinding">
         <textMessageEncoding />
         <security authenticationMode="SecureConversation">
           <secureConversationBootstrap authenticationMode="SspiNegotiated" />
         <httpTransport />


    What's next? get this blog rss updates or register for mail updates!

    Tuesday, March 17, 2009

    Which Binding to Use - WSHttpBinding or WS2007HttpBinding?


    The default binding in Wcf 3.0 is WSHttpBinding. Wcf 3.5 brings the new WS2007HttpBinding binding but WSHttpBinding is still the default. These bindings do not interoperate together well due to the fact that WS2007HttpBinding uses some newer standards.

    When the client uses WS2007HttpBinding and the server employs WSHttpBinding we may get this exception in the client side:

    Secure channel cannot be opened because security negotiation with the remote endpoint has failed. This may be due to absent or incorrectly specified EndpointIdentity in the EndpointAddress used to create the channel. Please verify the EndpointIdentity specified or implied by the EndpointAddress correctly identifies the remote endpoint.

    And the inner exception is:

    "The message could not be processed. This is most likely because the action '' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding."

    On the server side trace we see

    System.ServiceModel.EndpointNotFoundException, System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089

    And the inner exception:

    There was no channel that could accept the message with action ''.

    When the client uses WSHttpBinding and the server employs WS2007HttpBinding we would get the same exceptions with being replaced by

    The reason for the errors is the different WS-Trust versions between the bindings. WS-Trust is used when the negotiateServiceCredential or establishSecurityContext settings are set to true (which is the default). In these cases infrastructure messages are exchanged between the client and the server and these messages require the WS-Trust version to match.

    We can see the different versions if we use the reflector to check the bindings static constructors.

    In WSHttpBinding:

    static WSHttpBinding()
      WSMessageSecurityVersion = MessageSecurityVersion.WSSecurity11WSTrustFebruary2005

    In WS2007HttpBinding:

    static WS2007HttpBinding()
      WS2007MessageSecurityVersion = MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13

    So, which binding to use?
    In many cases this does not matter since both bindings expose similar functionality.
    You might want to consider the following:

  • WSHttpBinding is supported by .Net 3.0 clients.

  • WS2007HttpBinding uses WS-* standards while WSHttpBinding uses drafts. You might face a requirement to work with the standard.

  • Different soap stacks support different standards so if you need to interoperate with a specific framework verify the standards it supports.

  • In the long run WS2007HttpBinding should be used as it supports the actuall standard.

  • Nevertheless, for most services this decision will probably only have a very minor effect.


    What's next? get this blog rss updates or register for mail updates!

    Thursday, March 12, 2009

    OpenGIS With .Net 2.0 And WCF


    Geospatial and location based services became very popular these days. One concern for developers of such applications is how to represent the data in the system. This includes simple data types such as points or coordinate systems and complex ones such as advanced topologies. The correct approach is of course to use types from the standard schema set of the Open Geospatial Consortium (OGC).

    For a .Net developer this may imply the following needs:

  • Use xsd.exe to generate classes for serizliation

  • Create .Net 2.0 / WCF web services that utilize these schemas

  • Consume Wsdl's with these schemas

  • Unfortunetely the OpenGIS standard schemas are not interoperable with .Net. This has already been noticed by developers for older OpenGIS versions but newer versions seem to be equality incompatible.

    If you only want the fix without the details download it here and see in the end of the post the fix details:

    Here are some of the errors one gets when trying to consume Gml 3.1.1 and Gml 3.2.1 schemas in .Net:

    Gml 3.1.1 - WCF

    While using "add service reference" we get this error:

    Custom tool error: Failed to generate code for the service reference 'ServiceReference1'. Please check other error and warning messages for details.

    And after this an empty proxy code is generated:

    namespace ConsoleApplication1.ServiceReference1 {


    Gml 3.1.1 - .Net 2.0

    The wsdl importing stage seems to work fine. Let's build a one line client:

    WebReference.Service c = new WebReference.Service();

    Such a simple client - what can possibly go wrong? Well nothing, except this:

    "There was an error reflecting property '_ReferenceSystem'."

    "There was an error reflecting type 'ConsoleApplication1.WebReference.AbstractReferenceSystemType'."

    "There was an error reflecting property 'Item'."
    "There was an error reflecting property 'Text'."

    "Member 'Text' cannot be encoded using the XmlText attribute. You may use the XmlText attribute to encode primitives, enumerations, arrays of strings, or arrays of XmlNode."

    And this is after I have omitted some inner exceptions.

    In some cases (depending on .Net 2.0 patch level) the below exception will appear - not much improvement:

    Unable to generate a temporary class (result=1).
    error CS0029: Cannot implicitly convert type 'ConsoleApplication70.localhost.LineStringSegmentType' to 'ConsoleApplication70.localhost.LineStringSegmentType[]'
    error CS0029: Cannot implicitly convert type 'ConsoleApplication70.localhost.LineStringSegmentType' to 'ConsoleApplication70.localhost.LineStringSegmentType[]'

    Finally, depending in the types we reference, we might get this one as well:

    There was an error reflecting type 'ConsoleApplication70.localhost.TopoSurfacePropertyType'.

    Gml 3.2.1 - WCF

    Proxy is generated but the simplest client throws this exception chain:

    There was an error reflecting type 'ConsoleApplication1.ServiceReference1.RingPropertyType'.

    "There was an error reflecting type 'ConsoleApplication1.ServiceReference1.RingType'."


    "Member 'Text' cannot be encoded using the XmlText attribute. You may use the XmlText attribute to encode primitives, enumerations, arrays of strings, or arrays of XmlNode."

    Gml 3.2.1 - .Net 2.0

    Guess what?

    "There was an error reflecting property '_ReferenceSystem'."

    "There was an error reflecting type 'ConsoleApplication1.WebReference.AbstractReferenceSystemType'."


    "Member 'Text' cannot be encoded using the XmlText attribute. You may use the XmlText attribute to encode primitives, enumerations, arrays of strings, or arrays of XmlNode."

    Why these errors happen?

    The errors appear in run-time when we instantiate the client proxy or web service. At this stage .Net creates the serialization assembly for each type and fails to do it for the proxy. Actually if we have marked the "generate serialization assembly" build option we could already see these errors in compile time.

    Now what?

    We need to fix the schemas or the proxy in order to make them interoperable with .Net. The fix must be compatible with the original schema, so it may change the schema syntax but must result in an isomorphic schema.

    Making Gml 3.2.1 work

    There are two reasons for this schema incomparability:

  • Cyclic schema references

  • From gml.xsd:

    <include schemaLocation="deprecatedTypes.xsd"/>

    From deprecatedTypes.xsd:

    <include schemaLocation="gml.xsd"/>

    One way to solve this is to remove deprecatedTypes.xsd altogether - it is not really required. We'll be nicer and just replace inside it the reference to gml.xsd with these direct references:

    <include schemaLocation="dynamicFeature.xsd"/>
    <include schemaLocation="topology.xsd"/>
    <include schemaLocation="coverage.xsd"/>
    <include schemaLocation="coordinateReferenceSystems.xsd"/>
    <include schemaLocation="observation.xsd"/>
    <include schemaLocation="temporalReferenceSystems.xsd"/>

  • Non-string lists

  • .Net does not support the xsd:list data type. When the list is of strings it works anyway since unresolved types are treated as strings. But for other types it is not supported. MSDN contains some more information on xsd:list support in .Net.

    basicTypes.xsd contains this:

    <simpleType name="doubleList">
         <documentation>XML List based on XML Schema double type. An element of this type contains a space-separated list of double values</documentation>
       <list itemType="double" />

    Which becomes this in the .Net proxy:

    public double[] Value {
      get {
        return this.valueField;
      set {
        this.valueField = value;

    which causes a run-time error since the XmlTextAttribute is only appropriate on strings.

    The solutions is to replace all non-string lists in the schema to strings so the above becomes:

    <list itemType="string" />

    And after this Gml 3.2.1 classes are serializable by .Net!

    Making Gml 3.1.1 work

    This version has two issues:

  • Same issue with lists as in 3.2.1 - same fix

  • I've seen this one a couple of times. Basically when there is a multidimensional array of a type which has a single child element in some cases .Net code generation is incorrect. Don't ask, long story... Just replace in geometryPrimitives.xsd:

  • <complexType name="LineStringSegmentArrayPropertyType">
        <element ref="gml:LineStringSegment" minOccurs="0" maxOccurs="unbounded"/>


    <complexType name="LineStringSegmentArrayPropertyType">
        <element ref="gml:LineStringSegment" minOccurs="0" maxOccurs="unbounded"/>
        <any />

    And we have 3.1.1 working as well!

    Download fix

    I have uploaded the fixed schemas to save your time:

    After you extract the zip the fixed schemas are in the below folders:



    What's next? get this blog rss updates or register for mail updates!

    Thursday, March 5, 2009

    Cryptic WCF error messages (part 1 of N)


    If you are a WCF developer then sooner or later you are going to meet some cryptic error messages. No, they are not as intimidating as “access violation at address FFFFFF” and the blue screen of death, but is “Keyset does not exist“ and the white screen of trace any better?

    This is the first out of a serious of posts in which I'll try to diminish the mystery of these errors. This time I’ll examine an X.509 related issue.

    The other day I was configuring my WsHttpBinding with X.509 certificates used for digital signature and encryption. When I ran my client application I got that annoying

    An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.

    I hurried up and configured WCF tracing on my service only to get

    The EncryptedKey clause was not wrapped with the required encryption token 'System.IdentityModel.Tokens.X509SecurityToken'.

    This error is not so clear for those of us not familiar with the wire format of web services. However it does contain the essence of the problem: The client and the server are not using matching X.509 certificates. In order for the service to decrypt the message sent by the client it must use an X.509 containing a private key that matches the public key in the X.509 that the client is using for encryption.

    Now if you (like me at the time) insist that you are using the correct certificate, I suggest you would double and triple check the X.509 references in your web/app.config. If that doesn't help - remove and reinstall the relevant certificates from the windows certificate store. You’ll be surprised to find out you used an old version of the certificate at the client side or a wrong reference at the server. One common scenario where this can happen is if you are temporarily using the WCF or WSE sample certificates – it seems there are a few versions of them.


    What's next? get this blog rss updates or register for mail updates!