Return-Path: Delivered-To: apmail-ws-fx-dev-archive@www.apache.org Received: (qmail 99205 invoked from network); 13 Jul 2005 06:05:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Jul 2005 06:05:59 -0000 Received: (qmail 72065 invoked by uid 500); 13 Jul 2005 06:05:57 -0000 Delivered-To: apmail-ws-fx-dev-archive@ws.apache.org Received: (qmail 71995 invoked by uid 500); 13 Jul 2005 06:05:56 -0000 Mailing-List: contact fx-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list fx-dev@ws.apache.org Received: (qmail 71982 invoked by uid 99); 13 Jul 2005 06:05:56 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jul 2005 23:05:56 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [194.138.37.40] (HELO gecko.sbs.de) (194.138.37.40) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jul 2005 23:05:52 -0700 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j6D65TPG002474; Wed, 13 Jul 2005 08:05:30 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j6D65T5i030901; Wed, 13 Jul 2005 08:05:29 +0200 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Jul 2005 08:05:28 +0200 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: RES: AW: AW: order of sign and encr in .NET - .Net interoperability Date: Wed, 13 Jul 2005 08:05:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RES: AW: AW: order of sign and encr in .NET - .Net interoperability Thread-Index: AcWEVkNLZqs+GymcSiWHdyLsf1aRvQBwBerQACR1TtAAFd60EAAAbcfQABuxHUA= From: "Dittmann, Werner" To: "Steve Behrendt" Cc: , =?iso-8859-1?Q?G=FCrkan_Vural?= , "Granqvist, Hans" , X-OriginalArrivalTime: 13 Jul 2005 06:05:28.0901 (UTC) FILETIME=[DE80FF50:01C58770] X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Steve, thanks for testing it. When we introduced the millisecond stuff I was pretty sure we will hit some interop problems with this :-).=20 Thanks to Dims we can set it via deployment files now. Anyhow, currently we have 3 main issues with regard to .Net interoperability: - .Net does not yet support the WS-I specs with regard to security - .Net doesn't like the timestamps with the added millisecond precision - Need to set an Axis specific parameter=20 (enableNamespacePrefixOptimization) to false > -----Urspr=FCngliche Nachricht----- > Von: Steve Behrendt [mailto:steve@weg.com.br]=20 > Gesendet: Dienstag, 12. Juli 2005 18:53 > An: Dittmann, Werner > Cc: brian@sweetxml.org; G=FCrkan Vural; Granqvist, Hans;=20 > fx-dev@ws.apache.org > Betreff: RES: RES: AW: AW: order of sign and encr in .NET >=20 >=20 > Werner, >=20 > I have found it. The attribute is in the WSConstants.java class. > I tried it with my .NET WS and it works fine. >=20 > Is there a way to change the attribute in the WSConstants file without > change the file directly? Because that isn't a nice way to=20 > configure the > client to work with a .net wse2.0 webserver in this way, I think.=20 > E.g. for an interop scenario... >=20 > Steve >=20 >=20 > -----Mensagem original----- > De: Steve Behrendt=20 > Enviada em: ter=E7a-feira, 12 de julho de 2005 13:37 > Para: 'Dittmann, Werner' > Cc: brian@sweetxml.org; G=FCrkan Vural; Granqvist, Hans; > fx-dev@ws.apache.org > Assunto: RES: RES: AW: AW: order of sign and encr in .NET >=20 >=20 > Werner, >=20 > Sorry, but I can't find an atribute for that in the=20 > WSSConfig.java file. > The only attributes are:=20 > protected static WSSConfig defaultConfig =3D getNewInstance(); > protected String wsse_ns =3D WSConstants.WSSE_NS_OASIS_1_0; > protected String wsu_ns =3D WSConstants.WSU_NS_OASIS_1_0; > protected boolean qualifyBSTAttributes =3D false; > protected boolean prefixBSTValues =3D false; > protected boolean targetIdQualified =3D true; > protected boolean wsiBSPCompliant =3D false; > protected boolean processNonCompliantMessages =3D true; > public static final int TIMESTAMP_IN_SECURITY_ELEMENT =3D 1; > public static final int TIMESTAMP_IN_HEADER_ELEMENT =3D 2; > protected int timestampLocation =3D TIMESTAMP_IN_SECURITY_ELEMENT; >=20 > One of them is the correct one? >=20 > Steve >=20 > -----Mensagem original----- > De: Dittmann, Werner [mailto:werner.dittmann@siemens.com] > Enviada em: ter=E7a-feira, 12 de julho de 2005 03:16 > Para: Steve Behrendt > Cc: brian@sweetxml.org; G=FCrkan Vural; Granqvist, Hans; > fx-dev@ws.apache.org > Assunto: AW: RES: AW: AW: order of sign and encr in .NET >=20 >=20 > Steve, all, >=20 > about your first question: yes, that was the understanding > of a e-mail discussion we had some time ago: WSE does > not yet support WS-I (inclusivenamespace). >=20 > Your other question: yes, there is a subtle difference > between the working request you sent last Friday. The > difference is in the Timestamp. The format of the date/time > of the new request now includes the milliseconds. We added > the milliseconds due to some other interop problems and > because the XML Schema requires the milliseconds AFAIK. >=20 > But as usual you can switch off the milliseconds (in the > WSConfig file). Look for a boolean there. >=20 > Regards, > Werner >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Steve Behrendt [mailto:steve@weg.com.br]=20 > > Gesendet: Montag, 11. Juli 2005 14:58 > > An: Werner Dittmann > > Cc: brian@sweetxml.org; Dittmann, Werner; G=FCrkan Vural;=20 > > Granqvist, Hans; fx-dev@ws.apache.org > > Betreff: RES: RES: AW: AW: order of sign and encr in .NET > >=20 > >=20 > > Werner, > >=20 > > Thanks. "InclusiveNamespace" is stuff of the WS-I, but WSE=20 > > doesn't support this stuff (inclusivenamespace), therefore=20 > > the WSE dosn't accept the signature. Have I understand it right? > >=20 > > I have tried it and found 2 problems. When I use the wss4j.jar file > > (the newest version) the "inclusivenamespace"-stuff is added,=20 > > but when=20 > > I use the "src" files of the project folder the=20 > > "inclusivenamepsace" isn't > > added - without any changes on the wssconfig.java file. > >=20 > > Now the java-client send a soap-message without the=20 > > "inclusivenamespace"=3Dstuff, > > due to the WS-I, but the WSE still dowsn't accept the=20 > > signature. The exception is > > still the same: > >=20 > > AxisFault > > faultCode:=20 > > {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec > > urity-secext-1.0.xsd}FailedCheck > > faultSubcode:=20 > > faultString: Microsoft.Web.Services2.Security.SecurityFault:=20 > > The signature or decryption was invalid > > at=20 > >=20 > Microsoft.Web.Services2.Security.Security.LoadXml(XmlElement element) > > at=20 > > Microsoft.Web.Services2.Security.SecurityInputFilter.ProcessMe > > ssage(SoapEnvelope envelope) > > at=20 > > Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvel > > ope envelope) > > at=20 > > Microsoft.Web.Services2.WebServicesExtension.BeforeDeserialize > > Server(SoapServerMessage message) > > faultActor: http://localhost/WebServiceGMC/webservicegmc.asmx > >=20 > > The message is now: > >=20 > > > > > xmlns:soapenv=3D"http://schemas.xmlsoap.org/soap/envelope/"=20 > > xmlns:wsa=3D"http://schemas.xmlsoap.org/ws/2004/08/addressing"=20 > > xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"=20 > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> > > > > > xmlns:wsse=3D"http://docs.oasis-open.org/wss/2004/01/oasis-20040 > > 1-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand=3D"1"> > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"usernameTokenId-5862378"> > > usuario3 > > > Type=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > > username-token-profile-1.0#PasswordText">senha3 > > 2005-07-11T12:43:38.552Z > > 85DpuTBD4f14uJhdklt2hA=3D=3D > > > > > xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"> > > > > > Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > icalizationMethod> > > > Algorithm=3D"http://www.w3.org/2000/09/xmldsig#hmac-sha1"> > ignatureMethod> > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > =20 > > 6m7QGOVJoQGzFpxEIHqFISlwvOg=3D > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > =20 > > OrbC+oWPDqjF8d22jSIM+Z7mUf0=3D > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > =20 > > lr2fB700eMiCriQD7hrukW13eLk=3D > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > =20 > > aX77bRqKYnP9W1LZnXYy42DNhDI=3D > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > =20 > > hyPLuTIjh/hATPYWwwHxqiqU8ko=3D > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > =20 > > FAiQvuh29IyJoZTvOZl7MbHwFgU=3D > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > =20 > > zI1HezB6OwqrvwlhMDbvpKX3Bag=3D > > > > > > =20 > > = TplVnW4j2/FeIgZVI2PRctbAgHc=3D > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"STRId-25197736"> > > > URI=3D"#usernameTokenId-5862378"=20 > > ValueType=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-username-token-profile-1.0#UsernameToken"> > > > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-3779465"> > > 2005-07-11T12:43:38.536Z > > 2005-07-11T12:48:38.536Z > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-2929821"=20 > > soapenv:mustUnderstand=3D"0">uuid:672b03c0-f209-11d9-9218-cb301b > > 6f3efb > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-927929"=20 > > soapenv:mustUnderstand=3D"0">http://localhost:8080/WebServiceGMC > > /webservicegmc.asmx > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-15606519"=20 > > soapenv:mustUnderstand=3D"0">http://localhost/WebServiceGMC/webs > > ervicegmc.asmx?op=3DgetClientes > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-13328393"=20 > > soapenv:mustUnderstand=3D"0"> > > =20 > > http://schemas.xmlsoap.org/ws/2004/08/addressing/ > > role/anonymous > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-17160330"=20 > > soapenv:mustUnderstand=3D"0"> > > =20 > > http://schemas.xmlsoap.org/ws/2004/08/addressing/ > > role/anonymous > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-8706595"> > > > > > xmlns:ns1=3D"http://weg.net/service/">usuario1 > > > > > > > >=20 > >=20 > >=20 > > Any body see a difference between the working message sent by=20 > > the old wss4 > > and this from the up-to-date wss4j? > >=20 > > STEVE > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Mensagem original----- > > De: Werner Dittmann [mailto:Werner.Dittmann@t-online.de] > > Enviada em: s=E1bado, 9 de julho de 2005 04:19 > > Para: Steve Behrendt > > Cc: brian@sweetxml.org; Dittmann, Werner; G=FCrkan Vural;=20 > > Granqvist, Hans; > > fx-dev@ws.apache.org > > Assunto: Re: RES: AW: AW: order of sign and encr in .NET > >=20 > >=20 > > Brian, Steve, all, > >=20 > > looking at it I see the difference. Soemtime ago one of the > > contributers implemented some additons to be WS-I compliant. > > This "InclusiveNamespace" stuff is due to this, and as it turned > > out WSE is not yet ready to handle this. Due to this there is > > a boolean in WSSConfig.java (wsiBSPCompliant). If this boolean > > is true WSS4J works in BS-I compliant mode, setting it to false > > WSS4J works as before. > >=20 > > Can you crosscheck and give it a try? > >=20 > > Thanks, > > Werner > >=20 > > Steve Behrendt schrieb: > > > Brian, > > >=20 > > > You are right. I have tested the attached wss4j.jar file=20 > > too and I had > > > success. My client now can produce a message that the .net=20 > > client understand. > > > The signature should be right, because the .NET WebService=20 > > now don't respond > > > with the Exception (Signature invalid). > > >=20 > > > I have build 2 Messsages, one with the new and one with the=20 > > "old" wss4j.jar > > > and attached. > > >=20 > > > The old one, which don't works: > > >=20 > > > > > > > xmlns:soapenv=3D"http://schemas.xmlsoap.org/soap/envelope/"=20 > > xmlns:wsa=3D"http://schemas.xmlsoap.org/ws/2004/08/addressing"=20 > > xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"=20 > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> > > > > > > > xmlns:wsse=3D"http://docs.oasis-open.org/wss/2004/01/oasis-20040 > > 1-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand=3D"1"> > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" = wsu:Id=3D"usernameTokenId-12455463"> > > > usuario3 > > > > Type=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > > username-token-profile-1.0#PasswordText">senha3 > > > 2005-07-05T14:10:26Z > > > = yOBObBQ+sbevlt2XM0Xukg=3D=3D > > > > > > > xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"> > > > > > > > Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > xmlns:ec=3D"http://www.w3.org/2001/10/xml-exc-c14n#"=20 > > PrefixList=3D"soapenv wsa xsd xsi"> > > > > > > > Algorithm=3D"http://www.w3.org/2000/09/xmldsig#hmac-sha1"> > ignatureMethod> > > > > > > > > > > Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > xmlns:ec=3D"http://www.w3.org/2001/10/xml-exc-c14n#"=20 > > PrefixList=3D"wsa xsd xsi"> > > > > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > PmQSgFYbhiZciP5F6CRT5MZOPPk=3D > > > > > > > > > > > > > Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > xmlns:ec=3D"http://www.w3.org/2001/10/xml-exc-c14n#"=20 > > PrefixList=3D"soapenv wsa wsse xsd xsi"> > > > > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > jcRns/iJ1hxPJZEqUt1DIG0iDdo=3D > > > > > > > > > > > > > Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > xmlns:ec=3D"http://www.w3.org/2001/10/xml-exc-c14n#"=20 > > PrefixList=3D"xsd xsi"> > > > > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > TB1t5JzPv1WQ4uMX05qKqIl2s9o=3D > > > > > > > > > > > > > Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > xmlns:ec=3D"http://www.w3.org/2001/10/xml-exc-c14n#"=20 > > PrefixList=3D"xsd xsi"> > > > > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > erDZuYXo9WJn29GSh6Kood6guzw=3D > > > > > > > > > > > > > Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > xmlns:ec=3D"http://www.w3.org/2001/10/xml-exc-c14n#"=20 > > PrefixList=3D"xsd xsi"> > > > > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > QbIGZGq03FxN6tA2aE9d11/hvh0=3D > > > > > > > > > > > > > Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > xmlns:ec=3D"http://www.w3.org/2001/10/xml-exc-c14n#"=20 > > PrefixList=3D"xsd xsi"> > > > > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > Y4vVT5KZ9FKbXLumKcaqvHaWhHM=3D > > > > > > > > > =20 > > = aLSM1mbqLMfNLKPVoi7dRqeVMT4=3D > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"STRId-9734221"> > > > > URI=3D"#usernameTokenId-12455463"=20 > > ValueType=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-username-token-profile-1.0#UsernameToken"> > > > > > > > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-3874052"> > > > 2005-07-05T14:10:26Z > > > 2005-07-05T14:15:26Z > > > > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-3779465"=20 > > soapenv:mustUnderstand=3D"0">uuid:8912a6f0-ed5e-11d9-8c80-a1e409 > > 7e4740 > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-17160330"=20 > > soapenv:mustUnderstand=3D"0">http://localhost:8080/WebServiceGMC > > /webservicegmc.asmx > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-15606519"=20 > > soapenv:mustUnderstand=3D"0">http://localhost/WebServiceGMC/webs > > ervicegmc.asmx?op=3DgetClientes > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-2929821"=20 > > soapenv:mustUnderstand=3D"0"> > > > =20 > > http://schemas.xmlsoap.org/ws/2004/08/addressing/ > > role/anonymous > > > > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-7866553"> > > > > > > > xmlns:ns1=3D"http://weg.net/service/">1234 > > > > > > > > > > > >=20 > > > ------------------------------------------------------ > > >=20 > > > and the new one working: > > >=20 > > > > > > > xmlns:soapenv=3D"http://schemas.xmlsoap.org/soap/envelope/"=20 > > xmlns:wsa=3D"http://schemas.xmlsoap.org/ws/2004/08/addressing"=20 > > xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"=20 > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> > > > > > > > xmlns:wsse=3D"http://docs.oasis-open.org/wss/2004/01/oasis-20040 > > 1-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand=3D"1"> > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" = wsu:Id=3D"usernameTokenId-32956236"> > > > usuario3 > > > > Type=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- > > username-token-profile-1.0#PasswordText">senha3 > > > 2005-07-08T18:21:20Z > > > = RKPwh5ELWCBqUa0FhZtP9A=3D=3D > > > > > > > xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"> > > > > > > > Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > icalizationMethod> > > > > Algorithm=3D"http://www.w3.org/2000/09/xmldsig#hmac-sha1"> > ignatureMethod> > > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > FaQ7O3MS6a3e82I/jsfOhoDL+2M=3D > > > > > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > HinR+8MaMcU59CYiC25On0mv67U=3D > > > > > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > YmbgnQ/0F+mxw9s3NrOibFvRj8w=3D > > > > > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > iGemJhTiJd71u03JJWG22tLwfQ4=3D > > > > > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > 3m17MdDRPyAuUKi93W08Xdh2XQg=3D > > > > > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > 4Tb0yMaDPpAwiQXVpXdfJYWmvR0=3D > > > > > > > > > > > > > = Algorithm=3D"http://www.w3.org/2001/10/xml-exc-c14n#"> > > > > > > >=20 > = Algorithm=3D"http://www.w3.org/2000/09/xmldsig#sha1"> > > > =20 > > t0XvlW4iqR3Qo2SirI+6sqkG4gk=3D > > > > > > > > > =20 > > = Q1NqxNLzcBL4wIjc6UToVyJ6+Kc=3D > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"STRId-2780950"> > > > > URI=3D"#usernameTokenId-32956236"=20 > > ValueType=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-username-token-profile-1.0#UsernameToken"> > > > > > > > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-20727434"> > > > 2005-07-08T18:21:20Z > > > 2005-07-08T18:26:20Z > > > > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-3874052"=20 > > soapenv:mustUnderstand=3D"0">uuid:14e28260-efdd-11d9-a841-a743b9 > > d3b3f7 > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-2929821"=20 > > soapenv:mustUnderstand=3D"0">http://localhost:8080/WebServiceGMC > > /webservicegmc.asmx > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-867695"=20 > > soapenv:mustUnderstand=3D"0">http://localhost/WebServiceGMC/webs > > ervicegmc.asmx?op=3DgetClientes > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-3779465"=20 > > soapenv:mustUnderstand=3D"0"> > > > =20 > > http://schemas.xmlsoap.org/ws/2004/08/addressing/ > > role/anonymous > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-15606519"=20 > > soapenv:mustUnderstand=3D"0"> > > > =20 > > http://schemas.xmlsoap.org/ws/2004/08/addressing/ > > role/anonymous > > > > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssecurity-utility-1.0.xsd" wsu:Id=3D"id-9734221"> > > > > > > > xmlns:ns1=3D"http://weg.net/service/">1234 > > > > > > > > > > > >=20 > > >=20 > > -------------------------------------------------------------- > > --------- > > >=20 > > > Now we have an example to work on it. I have already=20 > > compared each other. > > > The main difference I had found was the=20 > > "CanonicalizationMethod" - Tag and the=20 > > > "Transform" Tag of the "Transforms" tags. > > > Perhaps there are the problems?!?!? > > >=20 > > > Steve > > >=20 > > >=20 > > > -----Mensagem original----- > > > De: brian@sweetxml.org [mailto:brian@sweetxml.org] > > > Enviada em: sexta-feira, 8 de julho de 2005 07:59 > > > Para: Dittmann, Werner; Steve Behrendt > > > Cc: G=FCrkan Vural; Granqvist, Hans; fx-dev@ws.apache.org > > > Assunto: Re: AW: AW: order of sign and encr in .NET > > >=20 > > >=20 > > > Werner, G=FCrkan and David, > > >=20 > > > Since Steve's post to the list concerning his problems=20 > > using wss4j with > > > UsernameToken Signature I've look at it again. My personal=20 > > conclusion is > > > that it once worked, but that in the meantime it's become=20 > > broken. At the > > > present time I can't say when exactly. I've tried various=20 > version of > > > wss4j, axis and bouncycastle and the only way I can get it=20 > > working is by > > > using an older version of wss4j that I build. I've attached=20 > > it, so you can > > > try it out and hopefully have a request come through. > > >=20 > > > Regards Brian > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >>G=FCrkan, > > >> > > >>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=FCngliche Nachricht----- > > >>>Von: G=FCrkan 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=20 > > signature value. it > > >>>processes all elements in the correct order. I am=20 > 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=20 > > there is a > > >>>sample soap message. Can anyone try to verify this? > > >>> > > >>>-- > > >>>gurkan > > >>> > > >>>Dittmann, Werner wrote: > > >>> > > >>> > > >>>>G=FCrkan, > > >>>> > > >>>>to me it seems a problem of BizTalk and/or the .Net WSE > > >>>>implementation. According to the OASIS WSS specification, > > >>>>chapter 5: > > >>>> > > >>>> > > >>>>As elements are added to a header block, > > >>>>they SHOULD be prepended to the existing elements. As such, > > >>>>the header block represents the signing and > > >>>>encryption steps the message producer took to create=20 > the message. > > >>>>This prepending rule ensures that the receiving application can > > >>>>process sub-elements in the order they appear in the > > >>>> 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. > > >>>> > > >>>> > > >>>>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=FCngliche Nachricht----- > > >>>>>Von: G=FCrkan 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 > > >>>>> > > = >>>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D- > > >>>>>Bu e-posta sadece yukarida isimleri belirtilen kisiler > > >>>>>arasinda =F6zel haberlesme amacini tasimaktadir. Size > > >>>>>yanlislikla ulasmissa l=FCtfen g=F6nderen 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. > > >>> > > >>>>> > > >>>>> > > >>> > > >>> > > = >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D- > > >>>Bu e-posta sadece yukarida isimleri belirtilen kisiler > > >>>arasinda =F6zel haberlesme amacini tasimaktadir. Size > > >>>yanlislikla ulasmissa l=FCtfen g=F6nderen 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=20 > > this message. > > >>> > > >> > > >=20 > >=20 > >=20 >=20