In order to implement the fix we need to understand the design using which the proxy files are generated.

Here is how the proxies work:

Let us suppose Demo being the service name.

There is one DemoWebService.as file which is derived
from interface IDemoService.as.
There is another file called BaseDemoWebService.as which actually does the SOAP serialization and deserialization.

The DemoWebService.as (ServiceImpl) delegates all the opreations to the BaseDemoWebService instance which is composed in it.

Now in order to add the SOAP security headers we should add a method in the DemoWebService.as like setAuthentication(or whatever you like). This code is similar to what Sven did in his post. Clearing and adding the security headers.

My custom method looks like:

public function setAuthentication(userName:String, password:String):void
{
import be.svendens.util.SOAPHeaderUtil;
import mx.rpc.soap.SOAPHeader;
if (_baseService != null) {
var customHeader:SOAPHeader = SOAPHeaderUtil.returnWSSEHeaderWithoutNonceAndTimestamp(userName, password);

//customHeader.mustUnderstand = true;
_baseService.clearHeaders();
_baseService.addHeader(customHeader);
}
}

The second and most important issue that needs to be fixed is in the BaseDemoWebService.as which is the core file. Here all the headers that we add are ignored as its everytime does the new for Header array.

The simple fix is in BaseDemoService file.

Find the line in method call

soap = enc.encodeRequest(args,headers);

and replace it with

soap = enc.encodeRequest(args, super.headers);

Just compile and verify the system will send your WSSE security headers to the webservice endpoint URI.

All these fixes can be automated easily by writing a simple tool. We have created one tool which runs on
the generated proxies and patches the proxies to support the WSSE headers exactly as mentioned above.

Please contact us in case you need that tool for free or in case you have any other issue.

Regards
Gaurav
gaurav_handa@nthdimenzion.com

or it’s better to provide a new variable:
var encodedNonce:String = base64Encode(nonce);
var created:String = generateTimestamp(timestamp);
var password64:String = getBase64Digest(nonce, created, password);
var token:Array = new Array(username, password64, encodedNonce, created);

Note that this is not present in Sven’s code so it was pretty much a problem of my own making. However, in the interests of disclosure…

Adding this attribute seems, at least in the implementation I’m working with, to make the server pay attention to the wsu:Id attribute in the UsernameToken element along with the Created and Expires elements in the Timestamp (i.e. If you pass a different Id attribute value through the same browser session before the Timestamp has expired then it’s throwing an error).

There’s two ways I’ve found to get around this:

1. Exclude the mustUnderstand attribute – I’m not sure if this is desirable or not (and I also have no idea what this would do to any implementations that actually track sessions for a reason), but the WSS specs (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf) state:

“When a header includes a mustUnderstand=”true” attribute:

The receiver MUST generate a SOAP fault if does not implement the WSS: SOAP Message Security specification corresponding to the namespace. Implementation means ability to interpret the schema as well as follow the required processing rules specified in WSS: SOAP Message Security.

The receiver must generate a fault if unable to interpret or process security tokens contained in the header block according to the corresponding WSS: SOAP Message Security token profiles.

Receivers MAY ignore elements or extensions within the element, based on local security policy.”

2. Keep the Id attribute value consistent until the Timestamp expires (or in theory throughout the life of the session) – This would seem to be a slightly more official way of doing it.

Either of these will make it work with the server implementation I’m using right now, although I’m storngly leaning towards the second option.

Again, all the usual caveats apply regarding this being a fix for my specific implementation and relying on the server-side guys to have locked things down well enough from a security angle that I can’t actually implement an insecure solution.

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
<wsse:UsernameToken>
<wsse:Username>username</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">encoded pasword</wsse:Password>
<wsse:Nonce>encoded nonce</wsse:Nonce>
<wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2009-09-14T10:53:01Z</wsu:Created>
</wsse:UsernameToken>
<wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2009-09-14T10:53:01Z</wsu:Created>
<wsu:Expires>2009-09-14T10:58:01Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>

2009-09-14T10:53:01Z
2009-09-14T10:58:01Z

(This’ll be pretty badly formatted but it should be decipherable).

The java client set the expiry time for the header as creation time + 5 mins, so I set the Flex entry to be the same (the created value is the same as the created entry within the UsernameToken).

Having said that I supposed it’s possible that the requirement for the timestamp may be Axis and/or implementation specific, so it may not be the solution to anyone’s problems bar mine but it’s a starting point.

There’s still one problem I haven’t overcome yet which is that if you call the same webservice operation a few times in a row after succeeding the first couple of times it permanently falls over with the error:

soapenv:Server.userException – org.xml.sax.SAXParseException: The prefix “soapenv” for attribute “soapenv:mustUnderstand” is not bound.

Once I get a solution for this I’ll post it here (I’m guessing it’s probably a server-side issue).

A perfectly working solution has not been found by anybody just yet as you can tell from the other comments. I’ll have to test what Stuart writes, comparing the headers from a Java-originated call to those of a Flex-originated call to see why the Flex ones won’t validate.
I’ll also have to test it against different versions of SOAP etc…

Hope to have a new post on the subject soon that FINALLY contains a 100% working solution.

Kind regards,
Sven