Gürkan, is this a real log of the request? If I save the file and try to open it with an XML editor it fails because of non-well formed document. Looking at it with emacs I see some linebreaks at unusual points, e.g. in the middle of an element name.
I'm not sure if this is due to e-mail transport or similar. But because you sent it as an attachement I would suspect that is not the case. Can you verify this? Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Gürkan Vural [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 8. Juli 2005 11:06 > An: Dittmann, Werner > Cc: Granqvist, Hans; [email protected] > Betreff: Re: AW: order of sign and encr in .NET > > > sorry wss4j can verify all elements but not final signature value. it > processes all elements in the correct order. I am trying to verify > username token signature with > http://www.w3.org/2000/09/xmldsig#hmac-sha1 algorithm. I can > verify what > i send to biztalk but not from biztalk. In the attachment there is a > sample soap message. Can anyone try to verify this? > > -- > gurkan > > Dittmann, Werner wrote: > > >Gürkan, > > > >to me it seems a problem of BizTalk and/or the .Net WSE > >implementation. According to the OASIS WSS specification, > >chapter 5: > > > ><quote> > >As elements are added to a <wsse:Security> header block, > >they SHOULD be prepended to the existing elements. As such, > >the <wsse:Security> header block represents the signing and > >encryption steps the message producer took to create the message. > >This prepending rule ensures that the receiving application can > >process sub-elements in the order they appear in the > ><wsse:Security> header block, because there will be no forward > >dependency among the sub-elements. Note that this specification > >does not impose any specific order of processing the > >sub-elements. The receiving application can use whatever order > >is required. > ></quote> > > > >This means, if the receiver sees an encryption sub-element > >before a Signature sub-element if processes encryption first. > >The ordering of elements is the _only_ information about the > >processing sequence. How could the receiver otherweise > >determine that it should first check Signature, then decrypt? > > > >Maybe you may crosscheck with the MS folks to clarfiy that? > >Are there known problems with BizTalk / .Net WSE? In general > >we tested interop with .Net WSE. > > > >Regards, > >Werner > > > > > > > >>-----Ursprüngliche Nachricht----- > >>Von: Gürkan Vural [mailto:[EMAIL PROTECTED] > >>Gesendet: Freitag, 8. Juli 2005 07:59 > >>An: Granqvist, Hans > >>Cc: [email protected] > >>Betreff: Re: order of sign and encr in .NET > >> > >> > >>Granqvist, Hans wrote: > >> > >> > >> > >>>>... biztalk outputs > >>>>DataReference above Signature element and this causes > >>>>decryption before signature and sign validation fails because > >>>>decryption changes the value of body element. > >>>> > >>>> > >>>> > >>>> > >>>Is it you or biztalk that implies processing order from > >>>the element order? > >>> > >>>Hans > >>> > >>> > >>> > >>> > >>Whatever order I send data to Biztalk it processes correctly. > >>Because my > >>java client (wss4j) puts the headers of last operation above > >>the others. > >>However Biztalk always sends DataReference above Signature > element and > >>my java client (wss4j) first processes the encrypted body > so signature > >>validation fails. > >> > >>-- > >>gurkan > >> > >>==========================================================- > >>Bu e-posta sadece yukarida isimleri belirtilen kisiler > >>arasinda özel haberlesme amacini tasimaktadir. Size > >>yanlislikla ulasmissa lütfen gönderen kisiyi bilgilendiriniz > >>ve mesaji sisteminizden siliniz. Turkiye Cumhuriyet Merkez > >>Bankasi A.S. bu mesajin icerigi ile ilgili olarak hicbir > >>hukuksal sorumlulugu kabul etmez. > >> > >>This e-mail communication is intended for the private use of > >>the people named above. If you received this message in > >>error, please immediately notify the sender and delete it > >>from your system. The Central Bank of The Republic of Turkey > >>does not accept legal responsibility for the contents of > this message. > >> > >> > >> > > > > ==========================================================- > Bu e-posta sadece yukarida isimleri belirtilen kisiler > arasinda özel haberlesme amacini tasimaktadir. Size > yanlislikla ulasmissa lütfen gönderen kisiyi bilgilendiriniz > ve mesaji sisteminizden siliniz. Turkiye Cumhuriyet Merkez > Bankasi A.S. bu mesajin icerigi ile ilgili olarak hicbir > hukuksal sorumlulugu kabul etmez. > > This e-mail communication is intended for the private use of > the people named above. If you received this message in > error, please immediately notify the sender and delete it > from your system. The Central Bank of The Republic of Turkey > does not accept legal responsibility for the contents of this message. >
