CXF does not really support the use-case that you are describing - it only has limited support for combining WS-Security with MTOM. By disabling MTOM before the BareOutInterceptor you are essentially inlining the attachment in the SOAP Body. The WS-Security layer however will store the encrypted bytes in an attachment. So while you are still saving bandwidth, you are incurring the computational cost of inlining the attachment.
I'm going to have a think about whether it's desirable for CXF to support this use-case, one advantage is that at least there is no risk that a attachment is not secured. Colm. On Fri, Oct 2, 2015 at 2:13 PM, anpoky <[email protected]> wrote: > Hi, > > The WSS policy for server says: > <wsp:Policy wsu:Id="myPolicy"> > <wsp:ExactlyOne> > <wsp:All> > <wsoma:OptimizedMimeSerialization /> > > So the mtom is turned on. The out message body must be signed and > encrypted. > The server not yet encrypted response has got a base64binary element and > when mtom is on, the serializer puts the content of this element to the > attachment (with a "Include" reference). > > Next, the message is signed and encrypted, but not the attachment. I am > little bit confused, cause the above WSS policy tells to optimize the > message for the encrypted message and not the message before encryption. > > However, I had to turn off mtom (mtom-enabled=false) before the > BareOutInterceptor and turn it on again after (with a interceptor). After > this it worked like expected. The base64binary element were not attached > and > the encrypted message is still mtom optimized and the cipherValues are > attached as expected. > > Is there any better solution than putting an inteceptor before and after > the > BareOutInterceptor? > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/No-mtom-before-message-encryption-tp5761406.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
