Hi all. We've continued testing MTOM+WS-Security Signature, we need interoperation with Microsoft clients, so swaRef is not an option and we need MTOM and signatures working well. We have found the following problems: 1) On the server side: 1.a) The WS-Security handlers are not invoked, to solve this change the protocol-bindings in the endpoint-config: | <endpoint-config> | <config-name>MTOM WSSecurity Endpoint</config-name> | <post-handler-chains> | <javaee:handler-chain> | <javaee:protocol-bindings>##SOAP11_HTTP ##SOAP11_HTTP_MTOM</javaee:protocol-bindings> | <javaee:handler> | <javaee:handler-name>WSSecurity Handler</javaee:handler-name> | <javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerServer</javaee:handler-class> | </javaee:handler> | </javaee:handler-chain> | </post-handler-chains> | </endpoint-config> | and change the endpoint config on the service implementation: | @BindingType(value = javax.xml.ws.soap.SOAPBinding.SOAP11HTTP_MTOM_BINDING) | @EndpointConfig(configName = "MTOM WSSecurity Endpoint") | 1.b) We always receive "Signature is invalid" error, we've found that the replacement of the xop:Include elements to the base64 representation was not made in deep. We've modifed SOAPFactoryImpl.createElement to invoke XOPContext.inlineXOPData when an xop:Include element is found. 1.c) When the replacement of xop:Include with the base64 representation occurs (see XOPContext.replaceXOPInclude) a content-type attribute is added to the parent element. This addition breaks the signature, that attribute was not present on the client side, so the signature is still invalid. We have modified the usage of an attribute with the usage of userData in the node. The problem here is that NodeImpl does not support the user data, so he have added that support. Right now, after 1.a 1.b and 1.c we have the signature verification working (testing with a message generated and signed manually, with some help of soapUI). The next problem: 2) On the client side 2.a) First of all, on the client side the endpoint config must be modified also (to get the ws-security handlers running): | <client-config> | <config-name>MTOM WSSecurity Client</config-name> | <post-handler-chains> | <javaee:handler-chain> | <javaee:protocol-bindings>##SOAP11_HTTP ##SOAP11_HTTP_MTOM</javaee:protocol-bindings> | <javaee:handler> | <javaee:handler-name>WSSecurityHandlerOutbound</javaee:handler-name> | <javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerClient</javaee:handler-class> | </javaee:handler> | </javaee:handler-chain> | </post-handler-chains> | and referenced from the client code: | ((StubExt)port).setConfigName("MTOM WSSecurity Client"); | 2.b) The message is sent with the binary data inline, and not as an attachment, we need attachments and not base64 encoding. We have a solution to this problem, but I believe it should be reviewed carefully. The solution is to invoke | XOPContext.visitAndRestoreXOPData(); | after the handlers execution (this is done on the JAXRPC client but not in JAXWS). I have modified CommonClient and DispatchImpl to make this invocation. Finally, we have a patch with the modifications on 1.b, 1.c and 2.b to the current trunk. I will upload it to a JIRA issue if the JBossWS team accepts this solution. Regards, Martin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132257#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...