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#4132257
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132257
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
