Adding SOAP:HEADER username and password with WSE 3.0

Question

I have successfully created a WS client that works correctly when NOT using authentication.

However, the server (WebSphere) now requires adding a ws-security username to

Answer 1

Got it working, unfortunately before reading wsanville's great answer.

To help others, I'm posting all the steps I needed to do to get it working with Visual Studio 2005:

• Install WSE 3.0, choose custom and select everything
• Read Implementing direct authentication with username token in WSE 3.0 for hints
• Relaunch Visual Studio 2005, now right-click on your project in the solution explorer, and you should have a WSE Settings 3.0 menu item and use that if you want to.
• Update your web references, this should create a new HTTP web service proxy class, with a different name, e.g. YourWsNameHttpServiceWse. This is essentially the same as running wsewsdl3.exe
• Use this new class, and you should have access to WSE methods and properties, such as SetClientCredential.

I ended up doing almost everything in code, instead of relying on the config-files that are built with my C# DLL. The code ended up looking like this:

FooBarHttpServiceWse wse = new FooBarHttpServiceWse();

wse.SetClientCredential(new UsernameToken(
    "username",
    "password",
    PasswordOption.SendPlainText));

wse.SetPolicy(new FooBarPolicy());
wse.CallSomeServerFunction(yourRequest)

I created my own policy, which looked like this:

using Microsoft.Web.Services3.Design;

// ...

public class FooBarPolicy : Policy
{
    public FooBarPolicy()
    {
        this.Assertions.Add(new UsernameOverTransportAssertion());
    }
}

Finally, the WebSphere server responded that A required header representing a Message Addressing Property is not present, and inspecting the outgoing message (using the nice tool Fiddler) I saw the SOAP fault from the server indicated that the Action header was missing.

I tried in vain to set the wsa:Action element myself:

using Microsoft.Web.Services3.Addressing;

// ...

wse.RequestSoapContext.Addressing.Action = new Action("CallSomeServerFunction");

The problem was that even if I set an action, when it was sent over the wire, it was empty. Turned out I had to open the WSE proxy class and edit an attribute there:

[System.Web.Services.Protocols.SoapDocumentMethodAttribute(
    "---Edit this to set wsa:Action---", 
    Use=System.Web.Services.Description.SoapBindingUse.Literal, 
    ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Bare)]
// ...
public SomeServerFunction(...)

After that, it all worked out nicely.