Gürkan, when I look at the SOAP request I see that you use UsernameToken as the key reference to sign the document _and_ to encrypt the document. WSS4J only implements the function to _sign_ the document with the username token. The encryption was not implemented as far as I can remember.
Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Gürkan Vural [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 8. Juli 2005 13:37 > An: Dittmann, Werner > Cc: Granqvist, Hans; [email protected] > Betreff: Re: AW: AW: order of sign and encr in .NET > > > sorry my mail client created these linebreaks. since all the > data was in > one line. anyway are there any known issues about verifying username > token signing with hmac-sha1 between wss4j and biztalk. biztalk can > verify my messages but i can not verify its messages. also i > can verify > my own messages. maybe it's because of the secret key created > by wss4j. > but if it were the reason then .net could not verify too. so the only > reason appeared in my mind is the whitespaces. is it possible? > > -- > gurkan > > Dittmann, Werner wrote: > > >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. > >> > >> > >> > > > ==========================================================- > 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. >
