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]
