WCF does not make Username Tokens over HTTP easy. For good reason too. People who pass credentials in the clear must be judged!

One day, you may find yourself forced into a corner, with a gun to your head,  having to break the rules and create a client to follow the WS-S Username Token Profile without transport level security. Like I did today.

Initially, as most people do, I figured it would be a simple case of tweaking an 'out of the box' WCF binding like wsHttpBinding or basicHttpBinding. Some people put in herculean efforts to fit their scenarios into the customBinding approach.

An even less obvious approach is to turn to the WCF's message inspector extensibility point. This by the way, works like a charm, as long as you are OK with using what amounts might as well be a loose wrapper around StringBuilder to complete the task. Good enough if you need run time flexibility.

I dug further and found that it is really easy to break the rules when it comes to SOAP Headers and the basicHttpBinding. Often forgotten, the <headers> configuration element to the rescue (namespaces & prefixes removed for brevity):

[sourcecode language="xml"]

<endpoint ... >
<headers>
<Security mustUnderstand="0">
<UsernameToken Id="ABC-123">
<Username>username</Username>
<Password>password</Password>
</UsernameToken>
</Security>
</headers>
</endpoint>

[/sourcecode]

So this may not give you much run time flexibility, but it's good to know that adding SOAP headers is not difficult at all. I wish I had known about the headers element a long time ago.