MTOM + WS Security = problem| JBoss.org Content Archive (Read Only)

15. Re: MTOM + WS Security = problem

richard_opalka Jun 27, 2007 4:32 AM (in response to mr_d)

"mr_d" wrote:

I agree, but if mtom is used and it is inlined, I don't see the point of using mtom: we can have the binary parameter inlined like the others. I thought that one of the advantages of mtom was to use xop which describes how to package binary data as an attachment.

@mr_d

Well MTOM can be inlined or not. If you're dealing with small attachments,
such as < 5k images or other binary data I don't see the problem if the
MTOM attachments are inlined. If you're dealing with bigger attachments
then I agree inlined MTOM attachmetns are not good for you. But it
depends on the SOAP stack how it will deal with MTOM attachments.
For example, some SOAP stacks are configured the following way:
* if attachment size is lesser than some preconfigured size then MTOM attachment is inlined
* if attachment size is greater than some preconfigured size then MTOM attachment is sent as MIME part.

Isn't this your problem?

Rio

16. Re: MTOM + WS Security = problem

mr_d Jun 27, 2007 6:14 AM (in response to mr_d)

"richard_opalka" wrote:

* if attachment size is lesser than some preconfigured size then MTOM attachment is inlined
* if attachment size is greater than some preconfigured size then MTOM attachment is sent as MIME part.

Thank you for this explanation,

Yes, Im working with larger file size such as 1-2MB. So, my problem is to use correctly mtom + ws security with jbossws.

:oD.

17. Re: MTOM + WS Security = problem

mrostan Feb 22, 2008 3:22 PM (in response to mr_d)

Hi, we are also trying to use WS-Security + MTOM in JBossWS 2.0.1 and 2.0.3, we are sending big files so we need binary attachments instead of inline encoded data.
Here is the result of our tests:

- In JBossWS 2.0.1 you must change the configuration of the endpoint by adding ##SOAP11_HTTP_MTOM to the bindings protocol:

<javaee:protocol-bindings>##SOAP11_HTTP ##SOAP11_HTTP_MTOM</javaee:protocol-bindings>

If ##SOAP11_HTTP_MTOM is not present, the handler is ignored, and the signature is not verified.

- In JBossWS 2.0.3 you don't need to add ##SOAP11_HTTP_MTOM, it seems to consider the handler anyway.

- In both versions we had problems sending the binary as an attachment (using SoapUI), we always receive: Signature is invalid
- Using a JBossWS client, we didn't find a way to send the binary data as an attachment, it is sent always encoded inline.
- If the binary data is sent inline the signature is verified (from the JBossWS client and also from SoapUI)

- So, we could not make MTOM + Attachments + WS-Security work together

Instead, we have moved to swaRef (simply annotating with @XmlAttachmentRef a DataHandler field) and everything works fine, you can remove the BindingType for MTOM.

- So, we have now swaRef + WS-Security working fine

There is some important difference between MTOM and swaRef? swaRef comes from ws-i, so I expect no interoperability problems.

Somebody has MTOM and WS-Security working?

Thanks,
Martin

18. Re: MTOM + WS Security = problem

mrostan Feb 26, 2008 12:13 PM (in response to mr_d)

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

19. Re: MTOM + WS Security = problem

asoldano Feb 26, 2008 12:24 PM (in response to mr_d)

Hi Martin,
for sure what you say is interesting, please attach the patch to a jira issue and link it here. Thank you!
We'll take a look at it and merge it to the trunk; point 2.b might be solved by http://jira.jboss.org/jira/browse/JBWS-1973.

20. Re: MTOM + WS Security = problem

mrostan Feb 26, 2008 12:41 PM (in response to mr_d)

Associated JIRA issue: http://jira.jboss.org/jira/browse/JBWS-2014