Werner, Yes ... we do have the problem you mentioned in the case of "Signarure after Encryption" but ... this case we are trying is Encrypt _after_ Signature (actions - "Timestamp Signature Encrypt" ). This is proven to work with MTOM and we have two test cases and the security sample in axis2 to test this scenario. :-)
I was able to reproduce the problem stated in the original mail with a slightly larger payload being encrypted. The problem seems to be with creating the base64 content from the binary content of the MTOM optmized msg only when the binary content is slightly large. I will look in to this more in the next few days. Thanks, Ruchith On 5/24/06, Werner Dittmann <[EMAIL PROTECTED]> wrote:
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 >>
