Hi Colm,
thanks for having a look into this!
Yes, the xml example is what gets sent across the wire!
However, I'm not even touching the SOAP document in my handler (which is
ahead of the WSDoAllSender in the client's handler chain).
I'm just setting the wss4j parameters dynamically (on the Axis
MessageContext mc):
entry ="alias"
action="Signature"
mc.setProperty(WSHandlerConstants.SIG_PROP_FILE,
"my.properties");
mc.setProperty(WSHandlerConstants.SIG_KEY_ID,
"DirectReference");
mc.setProperty(WSHandlerConstants.PW_CALLBACK_CLASS,
"myPasswordCallbackHandler");
mc.setProperty(WSHandlerConstants.SIGNATURE_USER, entry);
mc.setProperty(WSHandlerConstants.USER, entry);
mc.setProperty(WSHandlerConstants.ACTION, action);
And this is the wsdd file, which does work well:
<?xml version="1.0" encoding="UTF-8"?>
<deployment name="test" xmlns="http://xml.apache.org/axis/wsdd/";
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java";
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance";>
<transport name="http"
pivot="java:org.apache.axis.transport.http.HTTPSender"/>
<globalConfiguration>
<requestFlow>
<handler type="java:org.apache.ws.axis.security.WSDoAllSender" >
<parameter name="signatureUser" value="alias"/>
<parameter name="user" value="alias"/>
<parameter name="passwordCallbackClass"
value="myPasswordCallbackHandler"/>
<parameter name="action" value="Signature"/>
<parameter name="signaturePropFile" value="my.properties" />
<parameter name="signatureKeyIdentifier" value="DirectReference" />
</handler>
</requestFlow>
</globalConfiguration>
</deployment>
Bauer
Colm O hEigeartaigh schrieb:
Hi Bauer,
Yes, this is the right list for questions about wss4j.
Are the XML blobs you posted what gets sent across the wire? Both should
be perfectly valid. You're correct in saying that the second one
conforms to the c14n standard, but XML Security will just transform the
first example to the correct form when c14n'ing at the receiving end.
It sounds like a problem with the Axis SAAJ implementation...it's
extremely buggy. How are you constructing the DOM Document in your
handler? Can you attach the code of your custom handler?
Colm.
-----Original Message-----
From: Bauer Horscht [mailto:[email protected]]
Sent: 01 September 2009 17:17
To: [email protected]
Subject: Canonicalization / C14N problem setting WSDoAllSender
properties programmatically
Hi,
I want to use the signature action of the WSDoAllSender handler for my
WS client.
This works fine, as long as I use a wsdd file and load it with
FileProvider into the AxisClient.
But I want it to work using a SimpleProvider with a custom handler set
before WSDoAllSender.
This custom handler prepares the MessageContext for the WSDoAllSender
(such as mc.setProperty(WSHandlerConstants.SIGNATURE_USER, "Bob") and
WSDoAllSender even finishes without an Exception
However, now the server responds with a "The signature or decryption was
invalid... ".
I believe, the reason has something to do with c14n, since the messages
differ by their empty-elements, as shown in these extracts of the
crucial SignedInfo element:
FileProvider:
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; />
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; />
.....
</ds:SignedInfo>
SimpleProvider:
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#";>
</ds:CanonicalizationMethod>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1";>
</ds:SignatureMethod>
.....
</ds:SignedInfo>
Any idea why this happens?
I mean, isn't the second one the "correct one" in terms of complying to
the c14n standard?
Anyway, only the first one works.
Thanks
Bauer Horscht
PS: Is this the correct mail list? Didn't find a wss4j user list
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
