I've fixed AXIOM-408 and that solves the signature issue. Fresh 1.6.2-SNAPSHOT builds including that change are available here:
https://builds.apache.org/job/axis2-1.6/lastBuild/org.apache.axis2$distribution/ https://builds.apache.org/job/rampart-1.6/lastBuild/org.apache.rampart$rampart-dist/ Andreas On Sat, Jan 7, 2012 at 12:20, Andreas Veithen <[email protected]> wrote: > Thanks for the code, Jaime. > > I think that I have identified the root cause of the issue: > https://issues.apache.org/jira/browse/AXIOM-408 > > Andreas > > On Fri, Jan 6, 2012 at 00:43, Jaime Hablutzel Egoavil > <[email protected]> wrote: >> OK, the client code that generates two different signatures but transports >> the equivalent thing over the network is: >> >> DOOM enabled >> >> public class BinaryClient { >> >> public static void main(String[] args) throws Exception { >> >> ConfigurationContext ctx = >> ConfigurationContextFactory.createConfigurationContextFromFileSystem("D:\\software\\axis2-1.6.1\\repository", >> "D:\\software\\axis2-1.6.1\\samples\\mtom\\src\\client.axis2-2.xml"); >> RPCServiceClient client = new RPCServiceClient(ctx, null); >> Options opts = new Options(); >> opts.setAction("ns:echo"); >> EndpointReference to = new EndpointReference(); >> to.setAddress("http://localhost:8080/anywhere";); >> opts.setTo(to); >> >> opts.setProperty(org.apache.axis2.Constants.Configuration.ENABLE_MTOM, >> org.apache.axis2.Constants.VALUE_TRUE); >> //Set the rampart parameters >> opts.setProperty(WSSHandlerConstants.OUTFLOW_SECURITY, >> getOutflowConfiguration()); >> opts.setProperty(WSSHandlerConstants.INFLOW_SECURITY, >> getInflowConfiguration()); >> opts.setProperty(WSSHandlerConstants.USE_DOOM, >> org.apache.axis2.Constants.VALUE_TRUE); >> client.setOptions(opts); >> >> //Engage rampart >> client.engageModule("rampart"); >> >> DataHandler dh = new DataHandler(new >> FileDataSource("D:\\software\\axis2-1.6.1\\samples\\mtom\\build.xml")); >> >> client.invokeRobust(new QName("http://client.mtom.sample";, "echo"), >> new Object[]{dh}); >> } >> >> public static Parameter getOutflowConfiguration() { >> OutflowConfiguration ofc = new OutflowConfiguration(); >> ofc.setActionItems("Signature"); >> ofc.setUser("client"); >> ofc.setPasswordCallbackClass("sample.mtom.client.PWCBHandler"); >> ofc.setSignaturePropFile("client.properties"); >> >> ofc.setSignatureKeyIdentifier(WSSHandlerConstants.BST_DIRECT_REFERENCE); >> ofc.setEncryptionKeyIdentifier(WSSHandlerConstants.ISSUER_SERIAL); >> ofc.setEncryptionUser("service"); >> return ofc.getProperty(); >> } >> >> public static Parameter getInflowConfiguration() { >> InflowConfiguration ifc = new InflowConfiguration(); >> ifc.setActionItems("Signature"); >> ifc.setSignaturePropFile("client.properties"); >> return ifc.getProperty(); >> } >> >> } >> >> >> >> Without DOOM >> >> public class BinaryClient { >> >> public static void main(String[] args) throws Exception { >> >> ConfigurationContext ctx = >> ConfigurationContextFactory.createConfigurationContextFromFileSystem("D:\\software\\axis2-1.6.1\\repository", >> "D:\\software\\axis2-1.6.1\\samples\\mtom\\src\\client.axis2-2.xml"); >> RPCServiceClient client = new RPCServiceClient(ctx, null); >> Options opts = new Options(); >> opts.setAction("ns:echo"); >> EndpointReference to = new EndpointReference(); >> to.setAddress("http://localhost:8080/anywhere";); >> opts.setTo(to); >> >> opts.setProperty(org.apache.axis2.Constants.Configuration.ENABLE_MTOM, >> org.apache.axis2.Constants.VALUE_TRUE); >> //Set the rampart parameters >> opts.setProperty(WSSHandlerConstants.OUTFLOW_SECURITY, >> getOutflowConfiguration()); >> opts.setProperty(WSSHandlerConstants.INFLOW_SECURITY, >> getInflowConfiguration()); >> // opts.setProperty(WSSHandlerConstants.USE_DOOM, >> org.apache.axis2.Constants.VALUE_TRUE); >> client.setOptions(opts); >> >> //Engage rampart >> client.engageModule("rampart"); >> >> DataHandler dh = new DataHandler(new >> FileDataSource("D:\\software\\axis2-1.6.1\\samples\\mtom\\build.xml")); >> >> client.invokeRobust(new QName("http://client.mtom.sample";, "echo"), >> new Object[]{dh}); >> } >> >> public static Parameter getOutflowConfiguration() { >> OutflowConfiguration ofc = new OutflowConfiguration(); >> ofc.setActionItems("Signature"); >> ofc.setUser("client"); >> ofc.setPasswordCallbackClass("sample.mtom.client.PWCBHandler"); >> ofc.setSignaturePropFile("client.properties"); >> >> ofc.setSignatureKeyIdentifier(WSSHandlerConstants.BST_DIRECT_REFERENCE); >> ofc.setEncryptionKeyIdentifier(WSSHandlerConstants.ISSUER_SERIAL); >> ofc.setEncryptionUser("service"); >> return ofc.getProperty(); >> } >> >> public static Parameter getInflowConfiguration() { >> InflowConfiguration ifc = new InflowConfiguration(); >> ifc.setActionItems("Signature"); >> ifc.setSignaturePropFile("client.properties"); >> return ifc.getProperty(); >> } >> >> } >> >> >> And given that the server after canonicalization will only expect one type >> of signature it fails. >> >> >> >> >> On Thu, Dec 29, 2011 at 1:26 PM, Andreas Veithen <[email protected]> >> wrote: >>> >>> Can you sent use the code that produces the message causing the >>> problems, including everything you do to configure Rampart? That >>> should allow us to reproduce the problem. >>> >>> Andreas >>> >>> On Thu, Dec 29, 2011 at 17:16, Jaime Hablutzel Egoavil >>> <[email protected]> wrote: >>> > Axis 1.6.1, rampart 1.6.1, axiom 1.2.12 >>> > By the way I discovered that this problem only arises when using >>> > >>> > client.invokeRobust(new QName("http://client.mtom.sample";, "echo"), new >>> > Object[]{dh}); >>> > >>> > And not with >>> > >>> > client.sendReceive(elem) >>> > >>> > And I'm looking that the first one creates >>> > >>> > <soapenv:Body >>> > >>> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; >>> > wsu:Id="id-2"><echo xmlns="http://client.mtom.sample";><arg0 >>> > xmlns=""><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"; >>> > href="cid:[email protected]" >>> > /></arg0></echo></soapenv:Body> >>> > >>> > And the second one: >>> > >>> > <soapenv:Body >>> > >>> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; >>> > wsu:Id="id-2"><ns1:echo >>> > xmlns:ns1="http://client.mtom.sample";><arg0><xop:Include >>> > xmlns:xop="http://www.w3.org/2004/08/xop/include"; >>> > href="cid:[email protected]" >>> > /></arg0></ns1:echo></soapenv:Body> >>> > >>> > >>> > Anyway using the second it is working but with the first the stripped >>> > xmlns="" makes the signature value different so the server after >>> > canonicalization produces a different value and validation fails >>> > >>> > On Thu, Dec 29, 2011 at 4:31 AM, Andreas Veithen >>> > <[email protected]> >>> > wrote: >>> >> >>> >> What are the Axis2, Rampart and Axiom versions that you are using? >>> >> >>> >> Andreas >>> >> >>> >> On Tue, Dec 27, 2011 at 23:18, Jaime Hablutzel Egoavil >>> >> <[email protected]> wrote: >>> >> > Hi I want to post an apparent bug when DOOM option is activated in >>> >> > the >>> >> > client, so the SOAP message include xop:Include even when using >>> >> > WS-Signature >>> >> > and doesn't send the message in base64, this way getting advantage of >>> >> > MTOM. >>> >> > >>> >> > When using DOOM the canonicalized data to create the digest is: >>> >> > >>> >> > <soapenv:Body >>> >> > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; >>> >> > >>> >> > >>> >> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; >>> >> > wsu:Id="id-2"><echo >>> >> > >>> >> > >>> >> > xmlns="http://client.mtom.sample";><arg0>b3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ucHJvdmlkZXI9b3JnLmFwYWNoZS53cy5zZWN1cml0eS5jb21wb25lbnRzLmNyeXB0by5NZXJsaW4Kb3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ubWVybGluLmtleXN0b3JlLnR5cGU9amtzCm9yZy5hcGFjaGUud3Muc2VjdXJpdHkuY3J5cHRvLm1lcmxpbi5rZXlzdG9yZS5wYXNzd29yZD1hcGFjaGUKb3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ubWVybGluLmZpbGU9Y2xpZW50Lmprcw==</arg0></echo></soapenv:Body> >>> >> > >>> >> > But when DOOM is disabled the data is: >>> >> > >>> >> > <soapenv:Body >>> >> > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; >>> >> > >>> >> > >>> >> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; >>> >> > wsu:Id="id-2"><echo xmlns="http://client.mtom.sample";><arg0 >>> >> > >>> >> > >>> >> > xmlns="">b3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ucHJvdmlkZXI9b3JnLmFwYWNoZS53cy5zZWN1cml0eS5jb21wb25lbnRzLmNyeXB0by5NZXJsaW4Kb3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ubWVybGluLmtleXN0b3JlLnR5cGU9amtzCm9yZy5hcGFjaGUud3Muc2VjdXJpdHkuY3J5cHRvLm1lcmxpbi5rZXlzdG9yZS5wYXNzd29yZD1hcGFjaGUKb3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ubWVybGluLmZpbGU9Y2xpZW50Lmprcw==</arg0></echo></soapenv:Body> >>> >> > >>> >> > Look at the difference in red color. This causes the digest value to >>> >> > be >>> >> > different so the server gets confused and is unable to validate the >>> >> > signature when using DOOM in the client. A workaround seems to be to >>> >> > use >>> >> > only namespaced elements so the xmlns="" doesn't get generated never. >>> >> > >>> >> > I would like to know if someone has reached this problem when using >>> >> > MTOM >>> >> > + >>> >> > WS-Signature in axis 2. >>> >> > >>> >> > Other thing, DOOM option is not really well documented anywhere in >>> >> > axis2 >>> >> > website and I just found that it was available to make real MTOM with >>> >> > WS-Signature debugging the source code for three days u.u. >>> >> > >>> >> > Good bye >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Jaime Hablutzel - 9-9956-3299 >>> >> > >>> >> > (tildes omitidas intencionalmente) >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> > >>> > >>> > >>> > -- >>> > Jaime Hablutzel - 9-9956-3299 >>> > >>> > (tildes omitidas intencionalmente) >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> -- >> Jaime Hablutzel - 9-9956-3299 >> >> (tildes omitidas intencionalmente) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
