Thanks Nikola, I've just merged the fix. Colm.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nikola Ivacic Sent: 22 July 2009 15:47 To: Daniel Kulp Cc: [email protected]; Colm O hEigeartaigh Subject: Re: Interoperability problem with JBoss native stack This would be the improved method ... as Daniel suggested ... (I'll skip sending a patch file for now) public byte[] getToken() { Node n = getElement().getFirstChild(); StringBuffer buff = new StringBuffer(); while (n != null) { if (n instanceof Text) { buff.append(((Text)n).getData()); } n = n.getNextSibling(); } try { return Base64.decode(buff.toString()); } catch (Exception e) { return null;//It would be nice to log the excepton ... } } 2009/7/22 Daniel Kulp <[email protected]>: > > Quick couple of notes: > > 1) Good catch. We've run into this in CXF with various parsers as well. :-( > The Sun stax parser definitely splits thing more often than woodstox does. > > 2) NodeList nl = getElement().getChildNodes(); > Don't do this. Using NodeLists with xerces doms is expensive (and not thread > safe, although that wouldn't matter in this case as the DOM is only used on > the one thread). Do: > > Node nl = getElement().getFirstChild(); > while (nl != null) { > ..... > nl = nl.getNextSibling(); > } > > > Dan > > > On Wed July 22 2009 9:57:44 am Nikola Ivačič wrote: >> The problem is the XML parser: >> >> The method org.apache.ws.security.message.token.BinarySecurity::getToken >> decodes only first child text node and XML parser returns only the >> first chunk of text. >> The cert is then invalid since only a part of it is sent to a Crypto layer. >> >> That's why your sample works in my environment too. >> >> Suggested implemententation (correction) would be something like: >> >> public byte[] getToken() { >> //prev >> /*Text node = getFirstNode(); >> if (node == null) { >> return null; >> } >> try { >> return Base64.decode(node.getData()); >> } catch (Exception e) { >> return null; >> }*/ >> >> //new >> //better place for this might be a getFirstNode method >> NodeList nl = getElement().getChildNodes(); >> StringBuffer buff = new StringBuffer(); >> for (int i = 0; i < nl.getLength(); i++) { >> Node n = nl.item(i); >> if (n instanceof Text) { >> buff.append(((Text)n).getData()); >> } >> } >> >> try { >> return Base64.decode(buff.toString()); >> } catch (Exception e) { >> return null; >> } >> } >> >> 2009/7/21 Colm O hEigeartaigh <[email protected]>: >> > Hi Nikola, >> > >> > I'm able to load the certificate using WSS4J 1.5.7 without any problems. >> > Do you have the unlimited security policy files installed in the JDK >> > you're using? Also, try changing the signature crypto provider in your >> > policy from BouncyCastle to Merlin and see if that works. Can you debug >> > into the code and tell me what implementation is returned by >> > getCertificateFactory() in loadCertificate? >> > >> > Can you try the following code in your environment and tell me if it >> > works? You need to get a org.w3c.dom.Document instance ("doc" below) to >> > get it to work, just have a look at the WSS4J unit tests to see how it's >> > done. >> > >> > String token = >> > "MIIGQDCCBCigAwIBAgIBCjANBgkqhkiG9w0BAQ0FADCBlzELMAkGA1UEBhMCU0kxEjAQBgNV >> >BAgTCUxqdWJsamFuYTESMBAGA1UEBxMJTGp1YmxqYW5hMREwDwYDVQQKEwhEcm9wQ2hvcDEYMB >> >YGA1UECxMPVGVobmljbmEgU2x1emJhMREwDwYDVQQDEwhEcm9wQ2hvcDEgMB4GCSqGSIb3DQEJ >> >ARYRaW5mb0Bkcm9wY2hvcC5vcmcwHhcNMDkwNDE1MTUzMzAwWhcNMTAwNDE1MTUzMzAwWjCBpD >> >ELMAkGA1UEBhMCU0kxEjAQBgNVBAgTCUxqdWJsamFuYTESMBAGA1UEBxMJTGp1YmxqYW5hMREw >> >DwYDVQQKEwhEcm9wQ2hvcDEYMBYGA1UECxMPVGVobmljbmEgU2x1emJhMRkwFwYDVQQDExBtcG >> >cuZHJvcGNob3Aub3JnMSUwIwYJKoZIhvcNAQkBFhZuaWtvbGEuaXZhY2ljQGFtaXMubmV0MIIC >> >IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwPyBho3PojXAoYU0kBySUYJzSmZ57JdcZb >> >L+GvJFBvBmwexvUpO6ndyUmBVIfLb9aoRX0licQcY7suNWK3fSqAK4lZY8FO/SJNR4jtkvRHls >> >adeeoVWBBMDep9qnc1aR6mMP8X+ZVtZKwlIGRspPD2CbVaY68f9i/Dboj/oAWNwiYIYWlYjWjD >> >/HAq/Wvgjw88b6TK9mfrV0UTp64PjAoe98gpdpamMUXAfZtHehxTT3lerg92Hef3T1kYFwU8Vf >> >XEKiXpIalhIYS+E5JPZI88YEInMFdKiO+aVWOEP/PVbKJZEBVVlUJ8CX0X10EqkXs7m6gwfTB3 >> >GvNcTAvvI+yg8WXgOIn+V1Bwy6b72I8o+N+n3NmK7DWQMoo/OnD1pVDuTGWcJJ5z/2V0cAAa7a >> >W8G24ZN40umGeMLL5mkbUgnGmLOKWsFAM+SNKPa8SLUYCXYDQ7oOx2yY3n8X0vg/LtpDZIjLHi >> >/vXgJ1GxdVHowktZO7uR0yo1hmsdbN+0sOolRPrXsTLvIWZtHBwRkW0AsI4F6lsKdMyIpHZfMZ >> >YFs0GXu6XiFnfRjEnIsfEiTmmWIxB3kdxRBIg3X6N4ohK0wRW+js9zK7xdNTdQiyUVUa8qATAK >> >FRCO1iPazjeOpfmMUrJedaflhsoaVPmynQdNCPN7thM5Q44r9xaOPaJm8CAwEAAaOBhzCBhDAd >> >BgNVHQ4EFgQULzBEoXGnAEZjOK2u+7hWOWfjT+UwKgYDVR0lBCMwIQYIKwYBBQUHAwEGCisGAQ >> >QBgjcKAwQGCWCGSAGG+EIEATAfBgNVHSMEGDAWgBQzHhEFNbodfLNrEUv3/0eybyCquTALBgNV >> >HQ8EBAMCA7gwCQYDVR0TBAIwADANBgkqhkiG9w0BAQ0FAAOCAgEAlTVCTtV8ExT56xBo59WqXx >> >cHaHN1YpDyRgpNG8X/chFaVJlM8hnNoQdf2spauvTymkm0sutgXtFnGENoSFgicUq1sZLn+Zoq >> >AFyYFrU1226yNYYvTUoPIOac6qoslS5TqOw70LQ9n/TS2Cu9BU5G2xd04igwEEIvp0Sw9S1HFR >> >3SeW34Zwk7nA3RplrEMJZiyn28JeuYLy25ONZRNi5Y9K3+5qwGYKD5vDsZXmNYaxVpzBa8sHG5 >> >53JXoqWJcYajyDLYvzVBPdYI1xMDep3tVVHsIRR3NkZRx4bvD3Ie7c9Xd5zjkQQfCyr5yt8nQB >> >7hh1bj1YFRKQ2NjQ617feWbzmeXEXZKGtmc43l5XcQoOmCE9rtmDOn8MkM9LT8HAB5/N/WxZsC >> >aGZHlQBq6LJI09Srq9PAx3+8JibTURMZ6sGVlZA2NyeTe079m0c5XOWYh4S4qELV5EMljh0g/s >> >Be4oDS5uNmXbUyP/opZhTePYK7NWRUIkgXShmL75Ri/7AB+0ggFLURvV/HXU3lmnJ7zsEnyjU5 >> >WQk7QEUnPngMMlr6+FSaO0UlpFxukhcj+YmDYRxaYMzaK2Uo7M3o2eLVdHrvbRPtVf/M1D/wD5 >> >8+U8LndIDi17Q/sM7npcvU4cqwD839xNVk21X21SmI/fKn63NMmpLHAQAZXj66EwpnCo4="; >> > // Construct a Document "doc" as per the unit tests >> > org.apache.ws.security.message.token.X509Security sec = >> > new org.apache.ws.security.message.token.X509Security(doc); >> > sec.setToken(org.apache.ws.security.util.Base64.decode(token)); >> > X509Certificate cert = sec.getX509Certificate(crypto); >> > >> > Colm. >> > >> > >> > >> > -----Original Message----- >> > From: [email protected] [mailto:[email protected]] On Behalf >> > Of Nikola Ivacic Sent: 20 July 2009 13:59 >> > To: Colm O hEigeartaigh >> > Cc: [email protected] >> > Subject: Re: Interoperability problem with JBoss native stack >> > >> > Sorry for the previous mail, it was all messed up ... >> > (I have a really dumb mail client :-)) >> > >> > So here it is again: >> > >> > This is on my classpath: >> > XmlSchema-1.4.2.jar >> > activation-1.1.jar >> > axiom-api-1.2.7.jar >> > axiom-dom-1.2.7.jar >> > axiom-impl-1.2.7.jar >> > axis2-adb-1.4.1.jar >> > axis2-codegen-1.4.1.jar >> > axis2-kernel-1.4.1.jar >> > backport-util-concurrent-3.1.jar >> > bcprov-jdk16-142.jar >> > commons-codec-1.3.jar >> > commons-httpclient-3.1.jar >> > commons-logging-1.1.1.jar >> > jaxen-1.1.1.jar >> > log4j-1.2.15.jar >> > mail-1.4.jar >> > mex-1.4.1.jar >> > neethi-2.0.4.jar >> > opensaml-1.1.jar >> > rampart-1.4.mar >> > rampart-core-1.4.jar >> > rampart-policy-1.4.jar >> > rampart-trust-1.4.jar >> > testng-5.9-jdk15.jar >> > woden-api-1.0M8.jar >> > woden-impl-dom-1.0M8.jar >> > wsdl4j-1.6.2.jar >> > wss4j-1.5.7.jar >> > xalan-2.7.0.jar >> > xmlsec-1.4.1.jar >> > >> > p.s. The SOAP responses are not identical to the response in the >> > wss4j.log file. If you need any other files just let me know ... the >> > certs and keys are only for testing purposes anyway. >> > >> > Hope this helps, thanks. >> > >> > Nikola Ivačič >> > >> > 2009/7/20 Colm O hEigeartaigh <[email protected]>: >> >> Yes, this is the right mailing list :-) >> >> >> >> Can you attach the stacktrace of the exception that gets thrown by >> >> WSS4J? Also, the SOAP response would be great. >> >> >> >> Colm. >> >> >> >> -----Original Message----- >> >> From: Nikola Ivačič [mailto:[email protected]] On Behalf Of Nikola >> >> Ivacic Sent: 20 July 2009 07:38 >> >> To: [email protected] >> >> Subject: Interoperability problem with JBoss native stack >> >> >> >> Hi, >> >> >> >> If this is not the right mailing list I apologize. >> >> >> >> I have a problem with signed SOAP response from JBoss native stack >> >> (JBoss WS implementation). >> >> The X509 signed SOAP client call (Axis2 1.4 and Rampart 1.4) is >> >> correctly sent and understood by the server. >> >> The response contains X509 base 64 encoded certificate that WSS4j >> >> fails to parse. >> >> >> >> >> >> If I bypass invocation of >> >> public X509Certificate getX509Certificate(Crypto crypto) throws >> >> WSSecurityException >> >> in >> >> org.apache.ws.security.message.token.X509Security >> >> >> >> which gets invoked by >> >> org.apache.ws.security.processor .SignatureProcessor >> >> in >> >> public X509Certificate[] getCertificatesTokenReference(Element elem, >> >> Crypto crypto) >> >> and >> >> org.apache.ws.security.processor.BinarySecurityTokenProcessor >> >> in >> >> public X509Certificate[] getCertificatesTokenReference(Element elem, >> >> Crypto crypto) >> >> >> >> with my own (quick, naive and dirty) X509 parsing implementation, then >> >> SOAP response >> >> passes the Apache Rampart processing. >> >> >> >> >> >> I'm using WSS4j 1.5.7 and JBossWS 3.1.2 GA >> >> >> >> Where can I post this potential bug? >> >> What is the correct/standard binary format of the X509 certificate >> >> that gets >> >> base64 encoded in SOAP WS-Securtity header when using signing? >> >> >> >> >> >> Thanks for reply, >> >> >> >> Nikola Ivačič >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
