Roy, Ruchith, as far as I can remember the problem occured if the optimization was together with base64 encoded strings and if the signature was after encryption.
The encryption produces a bas64 encoded string with _no_ line break, this was then signed. MTOM converts is back into binary to save bandwidth. The receiver coverts it back into base64 but now inserts line breaks - this modification now breaks the Signature because of the added line breaks. This I meant with: MTOM optimization cannt reliably restore base64 strings because MTOM optimization always inserts line breaks at position 72 AFAIK. In normal cases this is not a problem but if the base64 string was signed then this could be disastrous for the Signature. Regards, Werner Ruchith Fernando wrote: > Hi Roy, > > Thanks a lot for the feedback ... seems like a bug in MTOM with > _large_ base64 text. > > I'm trying to reproduce your scenario ... I just checked the security > sample with the similar configuration (added wsa headers as parts to > be signed) and it worked with out a problem _with_ MTOM optimization > (both ways). > > I will try with more complex/larger encrypted response. > > Thanks, > Ruchith > > On 5/22/06, Reshef Roy <[EMAIL PROTECTED]> wrote: >> >> Ruchith, Werner. >> >> Werner was right! I have switched off MTOM >> optimization in the services.xml (service->client >> message), and it works without problems. I did leave >> MTOM optimization on the client Axis2 repository >> configuration (client->service), this is also not a >> problem (the client->service messages - I have two >> operations - are small and have a rather "flat" XML >> structure). >> >> If you need any more information, please let me know. >> >> Thanks again, >> >> / Roy >> >> >> the --- Reshef Roy <[EMAIL PROTECTED]> wrote: >> >> > >> > Ruchith, Werner. >> > >> > Thanks for your (again, fast :) replies. >> > Unfortunately I was already celebrating the weekend >> > when I read them :) Monday morning (CET, I'm in >> > Holland), I'll turn off the MTOM optimization and >> > see >> > where it leads. I'll post the results of course. >> > >> > As for thoughts: what Werner says does make some >> > sense >> > to me. I do not know the MTOM optimization mechanism >> > but the client->service SOAP message (see my >> > original >> > post, here it's truncated already) is rather small. >> > It >> > includes actually the identification of the action >> > and >> > one or two parameters only. >> > The service->client message is much larger and >> > depends >> > on the exact data one is querying for (the entities >> > we >> > ask for have children entities and the message can >> > include these ones as well). >> > Again, I am not familiar with the MTOM optimization >> > algorithm but if it resembles other encoding and >> > compression algorithms I do know, maybe it is more >> > "forgiving" for small amounts of data; or for a a >> > less >> > complex XML strructure? >> > >> > When Brian complained about it in March he also >> > complained about sending a complex XML document. >> > Like >> > him, my original message also included in the first >> > place as a CDATA an embedded XML document (generated >> > by a POJO object) but I have removed that and now I >> > only work with AXIOM to generate the SOAP message. >> > >> > Friday at midnight I don't have any brighter ideas, >> > more will follow Monday :) >> > >> > Nice weekend, >> > >> > / Roy >> > >> > --- Ruchith Fernando <[EMAIL PROTECTED]> >> > wrote: >> > >> > > Werner, Roy, >> > > >> > > Yes ... I think can give it a try by turning off >> > > MTOM optimization ... >> > > however the thing that troubles me is that the >> > > client -> service >> > > configuration seems to be the same as service >> > > ->client config and it >> > > (client -> service) worked with MTOM optimization, >> > > where is seems to >> > > be replacing the binary content properly to be >> > > decrypted at the >> > > service. >> > > >> > > Thoughts?? >> > > >> > > Thanks, >> > > Ruchith >> > > >> > > On 5/19/06, Dittmann, Werner >> > > <[EMAIL PROTECTED]> wrote: >> > > > Roy, >> > > > >> > > > Axis2 has a feature that optimizes transmission >> > of >> > > binary >> > > > data, AFAIK it convert base64 into real binary >> > and >> > > send it >> > > > over the wire. That save some bandwith. The >> > > problem is that >> > > > the receiver cannot restore the base64 from the >> > > binary in >> > > > exactly the same way as it was. Thus decryption >> > > and also >> > > > signatuire processing have problems. >> > > > >> > > > You may switch off this optimization an try >> > again, >> > > > no "optimizeParts" parameter. >> > > > >> > > > Regards, >> > > > Werner >> > > > >> > > > > -----Urspr�ngliche Nachricht----- >> > > > > Von: Reshef Roy [mailto:[EMAIL PROTECTED] >> > > > > Gesendet: Freitag, 19. Mai 2006 17:12 >> > > > > An: [email protected]; >> > > [email protected] >> > > > > Betreff: Decryption of a complex Axis2 SOAP >> > > message fails in >> > > > > WSS4J/XmlSec >> > > > > >> > > > > Hello WSS4J and Axis2 folks, >> > > > > >> > > > > I come back here on this issue which was >> > > discussed by >> > > > > Brian and Werner on the WSS4J mailing list in >> > > March, >> > > > > and has not been resolved. I am facing exactly >> > > the >> > > > > same problem. I believe it is a WSS4J/XMLSec >> > > issue, >> > > > > but I send it to both Axis2 and WSSS4J mailing >> > > lists. >> > > > > The original thread I copied from the mail >> > > archive and >> > > > > added at the bottom. >> > > > > >> > > > > My configuration is as follows: >> > > > > - My webservice is running on Axis2 1.0 >> > deployed >> > > on >> > > > > Tomcat 5.5.16 >> > > > > - My client application is a standalone Java >> > > > > application using an Axis2 1.0 client >> > repository >> > > > > - jre1.5.0_06 >> > > > > - relevant jar files in the Axis2 lib >> > directory >> > > (both >> > > > > the server and the client): wss4j-1.5.0, >> > > xmlsec-1.3.0, >> > > > > xalan-2.7.0 (probably not relevant), various >> > > > > javamail-1.4 jars (in case it has to do with >> > the >> > > MTOM >> > > > > attachment??). >> > > > > - the security configuration of both the >> > > webservice >> > > > > and the Axis2 client repository is similar to >> > > the one >> > > > > in the security sample of Axis2 1.0. >> > > > > >> > > > > I send a simple SOAP message from the client >> > to >> > > the >> > > > > service, and get a complex, eventually a very >> > > complex, >> > > > > SOAP message containing the data back. >> > > > > >> > > > > The client->server message works fine, both >> > when >> > > I >> > > > > configure it to be signed and encrypted and >> > when >> > > I >> > > > > don't. >> > > > > The server->client message works fine without >> > > > > signature and encryption, but fails on the >> > same >> > > > > exception as Brian's when the client side has >> > to >> > > > > decrypt it. >> > > > > >> > > > > At first I thought the fault was in our code, >> > as >> > > the >> > > > > generated XML was a mixture of XML generated >> > by >> > > AXIOM >> > > > > and "self-made" XML Strings in POJO code >> > > (however >> > > > > Axis2 does escape the < sign). In the past few >> > > days I >> > > > > cleaned our POJO code up completely, now the >> > XML >> > > > > message is generated solely by AXIOM. I still >> > > get the >> > > > > following exception: >> > > > > >> > > > > [java] org.apache.axis2.AxisFault: >> > > > > WSDoAllReceiver: security processing failed; >> > > nested >> > > > > exception is: >> > > > > [java] >> > > > > org.apache.ws.security.WSSecurityException: >> > > Cannot >> > > > > encrypt/decrypt data; nested exception is: >> > > > > [java] >> > > > > >> > > >> > >> org.apache.xml.security.encryption.XMLEncryptionException: >> > > > > Error while decoding >> > > > > [java] Original Exception was >> > > > > >> > > >> > >> org.apache.xml.security.exceptions.Base64DecodingException: >> > > > > Error while decoding >> > > > > [java] at >> > >> === message truncated === >> >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
