ws-fx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dittmann, Werner" <werner.dittm...@siemens.com>
Subject AW: AW: order of sign and encr in .NET
Date Fri, 08 Jul 2005 10:47:29 GMT
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:gurkan.vural@tcmb.gov.tr] 
> Gesendet: Freitag, 8. Juli 2005 11:06
> An: Dittmann, Werner
> Cc: Granqvist, Hans; fx-dev@ws.apache.org
> 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:gurkan.vural@tcmb.gov.tr] 
> >>Gesendet: Freitag, 8. Juli 2005 07:59
> >>An: Granqvist, Hans
> >>Cc: fx-dev@ws.apache.org
> >>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.
> 

Mime
View raw message