Adding SOAP implicit headers to WSDL

Question

My question is similar to this. How To Pass Soap Header When WSDL Doesn't Define It? But is different.

For a web service I use, all methods need authentication which is sent in cleartext inside a SOAP header. However, my WSDL doesn't include any soap header information. I have a custom platform tool which I must use to generate code from the WSDL. Since the header info is not available, am unable to use the generated class directly - I do not want to manually modify the code to accommodate the header.

I tried specifying the SOAP header in the WSDL but I failed to get the correct namespaces. The WSDL is here https://stage.totalcheck.sensis.com.au/service/webservice?wsdl and the SOAP header is as follows:

    <soapenv:Header>
        <wsse:Security>
            <wsse:UsernameToken>
                <wsse:Username>username</wsse:Username>
                <wsse:Password>password</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
   </soapenv:Header>

Can someone help me? Thanks!

`wsse` looks like the prefix normally used for WS-Security. Also, since SOAP services are meant to be self-describing, I'm at a loss to find a valid reason for headers not defined in the WSDL. — John Saunders, Apr 20 '11 at 14:24
That's agreeable. But like I said, I do not want to touch the auto generated class. Am just modifying this just to generate the class. — LVS, Apr 20 '11 at 14:47
The auto-generated class is a partial class. Maybe you can add the header to another class part. It wouldn't change when the auto-generated files are generated again. — John Saunders, Apr 20 '11 at 14:57

score 20 · Accepted Answer · answered Apr 21 '11 at 08:41

From a conceptual point of view, WSDL is not supposed to define headers. WSDL is only for defining the functional aspects of a service, like operations, messages, binding and endpoints. Messages and bindings define how the payload of messages should be encoded and formatted.

The headers of SOAP messages however do not belong to the payload. They are typically used for configuring non-functional properties of a SOAP processor. Security is such a non-functional property. The functional aspect of the payload is not affected. It is only assured that the communication is secured and the WS tool stack, not the service implementation, should take care of that.

So the missing piece is now a standard that allows for attaching some non-functional requirements to WSDL services, so that code generators can automatically derive which headers need to be sent and/or understand in order to fulfill the non-functional property as desired -- without having to manually deal with header fields. This standard exists and is called WS-Policy. A policy contains typically a set of alternatives that expose a set of requirements that both, provider and consumer should be able to fulfill. When two services are supposed to interact with each other, both policies are taken and a so called "effective policy" is calculated. It defines the common non-functional requirements. Using this information, provider and consumer can configure themselves to add required headers, like the WS-Security headers. WS-SecurityPolicy also defines a set of policies that can be used. WS-PolicyAttachment defines how such policies can be attached to a WSDL.

There are code generators that can deal with WS-Policies, e.g. Metro or Axis2

The header element IS defined in the wsdl/soap schema so it would be hard to say it's not supposed to be used: http://schemas.xmlsoap.org/wsdl/soap/ You could certainly use WS-SecurityPolicy but it's simply a different, albeit more specific, specification. — b_levitt, Oct 15 '12 at 21:26
Agreed, for a binding, WSDL [specifies](http://www.w3.org/TR/wsdl#_soap:header) how certain parts can be mapped to SOAP headers. However, I consider using this, from a conceptual point of view, a bad practice, since it ties your WSDL to specific bindings. I agree, that the question was also asked for the specific SOAP binding, so using the headers binding is probably fine, but using WS-Policy is a sounder way to go (i.e. it expresses the non-functional concern "make sure the request is authenticated" vs. sending specific headers). In the former case, the WS-stack knows already what to do. — vanto, Oct 16 '12 at 17:09
While I still disagree that it's "bad practice" (dated might be a better evaluation), I do now see that you are correct on pointing to the WS-SecurityPolicy in this case since the headers in the OP are those of WS-Security. +1 — b_levitt, Oct 16 '12 at 22:45

score 4 · Answer 2 · answered Oct 06 '12 at 04:45

You can add soap header information to method calls by decorating the methods in the proxy class generated from the wsdl with the SoapHeader attribute.

For example wsdl.exe will generate client proxy class Reference.cs for the web service reference when you "Add Web Reference". In the link mentioned above https://stage.totalcheck.sensis.com.au/service/webservice?wsdl there is a message suggestAddress which will translate to a method in the generated reference.cs client proxy code file when you add a web reference from visual studio. By default when this method is called there will be no Header in the soap envelope. To add a SoapHeader to the envelope for this request add a [SoapHeader("Security")] attribute to the top of the SuggestAddress method in the Reference.cs generated class, where "Security" is a class that inherits from SoapHeader base class.

Example for the above required Security SoapHeader you would create the following classes,

public partial class Security : SoapHeader
{
    public UserNameToken UserNameToken { get; set; }
}

public partial class UserNameToken
{
    public string UserName { get; set; }
    public string Password { get; set; }
}

Then you would decorate the SuggestAddress method in the reference.cs like followed,

[SoapHeader("Security")]
public suggestAddressesResult suggestAddresses([System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] addressSearch search) {
        object[] results = this.Invoke("suggestAddresses", new object[] {search});
        return ((suggestAddressesResult)(results[0]));
    }

This will ensure that every envelope created when method suggestAddress is invoked contains a security header that looks like the one mentioned above,

<soapenv:Header>
    <wsse:Security>
        <wsse:UsernameToken>
            <wsse:Username>username</wsse:Username>
            <wsse:Password>password</wsse:Password>
        </wsse:UsernameToken>
    </wsse:Security>

what is suggestAddresses refer here? I can't undershot. while impementing,. i got Error 'SoapwbApp.withHeader' does not contain a definition for 'Invoke' and no extension method 'Invoke' accepting a first argument of type 'SoapwbApp.withHeader' could be found (are you missing a using directive or an assembly reference?) — Sagotharan, Oct 16 '14 at 06:16

score 1 · Answer 3 · edited Nov 29 '13 at 16:18

Key for me in using this question to help myself was recognizing (as some pointed out) that the headers in question are those of WS-Security standard.

If your proxy generating tool is "custom" it seems logical that you might have a switch to automatically add the headers for WS-Security. However, if you're using WSDL.exe ("Add Web Reference" in Visual Studio), consider svcutil.exe instead ("Add Service Reference").

If you use a WCF proxy, you can override the given config and allow WCF to add the headers for you:

<security mode="TransportWithMessageCredential">
    <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
    <message clientCredentialType="UserName" algorithmSuite="Default" />
</security>

From there you can specify the password:

RemoteSvcProxy.TheirClient client = new RemoteSvcProxy.TheirClient();
client.ClientCredentials.UserName.UserName = "uname";
client.ClientCredentials.UserName.Password = "pwd";

I don't know what your custom tool is, but perhaps the framework it's based on also has similar configuration options.

Adding SOAP implicit headers to WSDL

3 Answers3

Linked