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]
