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: AW: order of sign and encr in .NET
Date Fri, 08 Jul 2005 13:18:51 GMT
Gürkan,

well, I'll check it using my testprograms. As you may have
noticed Brian sent an e-mail about the same topic stating
that it once worked, but some stopped working.

I checked the modifications done on the relevant code,
but could not see any problem at a first glance. I'll
try to setup my testenvironment for this and do some
re-tests.

As I understand the request you sent to the list was just
one line. If I remove the linebreaks this would then
be the original request?

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Gürkan Vural [mailto:gurkan.vural@tcmb.gov.tr] 
> Gesendet: Freitag, 8. Juli 2005 13:37
> An: Dittmann, Werner
> Cc: Granqvist, Hans; fx-dev@ws.apache.org
> 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: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.
> >>
> >>    
> >>
> 
> 
> ==========================================================-
> 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