Yaron Naveh's Web Services 2.0 Blog

Security Gotcha: Nonrepudiation

2009-12-30T10:21:00.000-08:00

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":

This is how the client request looks like:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
<soap:Header>
...
   <To soap:mustUnderstand="1" u:Id="_1" xmlns="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">https://www.someService.co.il/</To>
   ...
   <o:Security soap:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <u:Timestamp u:Id="_0" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
     <u:Created>2009-12-30T18:19:03.538Z</u:Created>
     <u:Expires>2009-12-30T18:24:03.538Z</u:Expires>
    </u:Timestamp>
    <o:BinarySecurityToken u:Id="uuid-b29856c4-1be8-4cf6-94ef-b3e2818b9924-1" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">...</o:BinarySecurityToken>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
     <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <Reference URI="#_0">
       <Transforms>
        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
       </Transforms>
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
       <DigestValue>ExzPg2kUjOQz2nFBMlhm+OT3GNY=</DigestValue>
      </Reference>
      <Reference URI="#_1">
       <Transforms>
        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
       </Transforms>
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
       <DigestValue>mN+2rmNLmjSJxbO4x+n/V6gGAb4=</DigestValue>
      </Reference>
     </SignedInfo>
     <SignatureValue>...</SignatureValue>
     <KeyInfo>
      <o:SecurityTokenReference>
       <o:Reference URI="#uuid-b29856c4-1be8-4cf6-94ef-b3e2818b9924-1" />
      </o:SecurityTokenReference>
     </KeyInfo>
    </Signature>
   </o:Security>
</soap:Header>
<soap:Body>
   <EchoString xmlns="http://tempuri.org/">
    <s>abcde</s>
   </EchoString>
</soap:Body>
</soap:Envelope>

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.

When your unit test is not implemented...

2009-12-26T08:29:00.000-08:00

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:

[Test]
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()".

Unit Test Legitimic Failures

2009-12-26T07:57:00.000-08:00

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:

[Test]
[Ignore]
public void SomeTest()
{
//...
}

The test is not red any more:

The XmlReader state should be Interactive

2009-12-26T07:44:00.000-08:00

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:

System.InvalidOperationException
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
r.MoveToContent();
XElement e = XElement.ReadFrom(r) as XElement;

Not all errors are red

2009-12-09T10:21:00.000-08:00

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.

Axis 2 WS-Security (rampart) FAQ

2009-11-20T08:30:00.000-08:00

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

Generating meaningful names from a url

2009-11-19T07:16:00.000-08:00

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.

http://www.myServer.com/Services/Sanity.asmx?WSDL - Sanity
http://www.myServer.com/Services/Sanity.asmx?wsdl=1&xsd=2 - Sanity
http://www.myServer.com/Services/Sanity12345678901234567890123456789012345678901234567890123456789012.asmx - Sanity1234567890123456789012345678901234567
http://www.myServer.com/Services/Sanity.asmx - Sanity
http://www.myServer.com/Services/Sanity/ - Sanity
http://www.myServer.com/Services/Sanity - Sanity
http://www.myServer.com/Services/Sanity?wsdl - Sanity_wsdl
http://www.myServer.com/Services/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]=='?';
}

BindingBox: Convert WCF Bindings

2009-08-22T09:46:00.000-07:00

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:

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:

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...

Debugging WCF

2009-07-28T10:45:00.000-07:00

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:

Cryptic WCF error messages (part 6 of N)

2009-07-28T10:29:00.000-07:00

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

log4net gotcha: AppDomains

2009-07-25T02:46:00.000-07:00

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.

Why lawyers make more money than programmers

2009-07-25T01:36:00.000-07:00

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:

SCOPE OF LICENSE
...
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...

Security in SOA

2009-07-03T11:59:00.000-07:00

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.

Test Drive in Skydrive

2009-06-28T10:54:00.000-07:00

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):

site:

reader:

If you will surf to

http://skydrive.live.com/

before you'll notice it you'll be in

http://cid-4999e5d00449874d.skydrive.live.com/

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 ;-)

Contract-First vs.Code-First, Still?

2009-06-27T12:40:00.001-07:00

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:

[WebMethod]
    public string HelloWorld() {
          return "Hello World";
    }

And this is auto generated for you:

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

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.

WCF proxy cleanup

2009-06-26T09:14:00.000-07:00

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:

proxy.close();

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.

Unit Tests Presentation

2009-06-25T05:46:00.000-07:00

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.

WSE2 With Visual Studio 2005, Anyone?

2009-06-22T13:40:00.001-07:00

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.

WSE3 is so... VS 2008

2009-06-22T13:24:00.000-07:00

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:

<microsoft.web.services3>
...
</microsoft.web.services3>

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();
proxy.DoSomething();

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:

serviceProxy.SetPolicy("ClientPolicy"); 

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...

Are WCF defaults considered harmful?

2009-06-20T07:26:00.000-07:00

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.

WCF Self Hosting Project Template

2009-06-19T13:40:00.000-07:00

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).

Installation

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 :)

Introducing WCF ClearUsernameBinding

2009-04-30T07:03:00.000-07:00

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.

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.
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\TestService.exe

And now the client:

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

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\Release\ClearUsernameBinding.dll

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

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

      <bindings>
         <clearUsernameBinding>
            <binding name="myClearUsernameBinding" messageVersion="Soap12">            
            </binding>
         </clearUsernameBinding>
      </bindings>

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\TestService.exe.config

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.

Example:

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

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:

<behaviors>
             <serviceBehaviors>
                  <behavior name="SampleServiceBehaviour">
...
                       <serviceCredentials>
                            <userNameAuthentication     userNamePasswordValidationMode="Custom"
                                customUserNamePasswordValidatorType="WebServices20.Validators.MyUserNameValidator, MyUserNameValidator" />
                       </serviceCredentials>
                  </behavior>
             </serviceBehaviors>
        </behaviors>
...
<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";            
client.EchoString("hello");

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

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

       <extensions>
          <bindingExtensions>
             <add name="clearUsernameBinding"    type="WebServices20.BindingExtenions.ClearUsernameCollectionElement   , ClearUsernameBinding" />
          </bindingExtensions>
       </extensions>
      
       <bindings>
          <clearUsernameBinding>
             <binding name="myClearUsernameBinding" messageVersion="Soap12">

             </binding>
          </clearUsernameBinding>
       </bindings>
      
    </system.serviceModel>

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):

<Envelope>
   <Header>
      <Security>
...
         <UsernameToken>
            <Username>yaron</Username>
            <Password>1234</Password>
         </UsernameToken>
      </Security>
   </Header>
   <Body>
      <EchoString xmlns="http://tempuri.org/">
         <s>hello</s>
      </EchoString>
   </Body>
</Envelope>

Conclusion
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.

Interoperability Gotcha: Visual Studio 2008 Proxy Flavours

2009-04-29T06:20:00.000-07:00

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

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

2009-04-26T01:32:00.000-07:00

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 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' namespace for BinarySecretSecurityToken, with a 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v1' 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="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v1" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">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:

WCF Performance: Making your service run 3 times faster

2009-04-18T04:56:00.000-07:00

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:

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

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:

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

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.

negotiateServiceCredential
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:

establishSecurityContext
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".

Summary
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.