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 <cohei...@progress.com>:
>
> 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 =
> "MIIGQDCCBCigAwIBAgIBCjANBgkqhkiG9w0BAQ0FADCBlzELMAkGA1UEBhMCU0kxEjAQBgNVBAgTCUxqdWJsamFuYTESMBAGA1UEBxMJTGp1YmxqYW5hMREwDwYDVQQKEwhEcm9wQ2hvcDEYMBYGA1UECxMPVGVobmljbmEgU2x1emJhMREwDwYDVQQDEwhEcm9wQ2hvcDEgMB4GCSqGSIb3DQEJARYRaW5mb0Bkcm9wY2hvcC5vcmcwHhcNMDkwNDE1MTUzMzAwWhcNMTAwNDE1MTUzMzAwWjCBpDELMAkGA1UEBhMCU0kxEjAQBgNVBAgTCUxqdWJsamFuYTESMBAGA1UEBxMJTGp1YmxqYW5hMREwDwYDVQQKEwhEcm9wQ2hvcDEYMBYGA1UECxMPVGVobmljbmEgU2x1emJhMRkwFwYDVQQDExBtcGcuZHJvcGNob3Aub3JnMSUwIwYJKoZIhvcNAQkBFhZuaWtvbGEuaXZhY2ljQGFtaXMubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwPyBho3PojXAoYU0kBySUYJzSmZ57JdcZbL+GvJFBvBmwexvUpO6ndyUmBVIfLb9aoRX0licQcY7suNWK3fSqAK4lZY8FO/SJNR4jtkvRHlsadeeoVWBBMDep9qnc1aR6mMP8X+ZVtZKwlIGRspPD2CbVaY68f9i/Dboj/oAWNwiYIYWlYjWjD/HAq/Wvgjw88b6TK9mfrV0UTp64PjAoe98gpdpamMUXAfZtHehxTT3lerg92Hef3T1kYFwU8VfXEKiXpIalhIYS+E5JPZI88YEInMFdKiO+aVWOEP/PVbKJZEBVVlUJ8CX0X10EqkXs7m6gwfTB3GvNcTAvvI+yg8WXgOIn+V1Bwy6b72I8o+N+n3NmK7DWQMoo/OnD1pVDuTGWcJJ5z/2V0cAAa7aW8G24ZN40umGeMLL5mkbUgnGmLOKWsFAM+SNKPa8SLUYCXYDQ7oOx2yY3n8X0vg/LtpDZIjLHi/vXgJ1GxdVHowktZO7uR0yo1hmsdbN+0sOolRPrXsTLvIWZtHBwRkW0AsI4F6lsKdMyIpHZfMZYFs0GXu6XiFnfRjEnIsfEiTmmWIxB3kdxRBIg3X6N4ohK0wRW+js9zK7xdNTdQiyUVUa8qATAKFRCO1iPazjeOpfmMUrJedaflhsoaVPmynQdNCPN7thM5Q44r9xaOPaJm8CAwEAAaOBhzCBhDAdBgNVHQ4EFgQULzBEoXGnAEZjOK2u+7hWOWfjT+UwKgYDVR0lBCMwIQYIKwYBBQUHAwEGCisGAQQBgjcKAwQGCWCGSAGG+EIEATAfBgNVHSMEGDAWgBQzHhEFNbodfLNrEUv3/0eybyCquTALBgNVHQ8EBAMCA7gwCQYDVR0TBAIwADANBgkqhkiG9w0BAQ0FAAOCAgEAlTVCTtV8ExT56xBo59WqXxcHaHN1YpDyRgpNG8X/chFaVJlM8hnNoQdf2spauvTymkm0sutgXtFnGENoSFgicUq1sZLn+ZoqAFyYFrU1226yNYYvTUoPIOac6qoslS5TqOw70LQ9n/TS2Cu9BU5G2xd04igwEEIvp0Sw9S1HFR3SeW34Zwk7nA3RplrEMJZiyn28JeuYLy25ONZRNi5Y9K3+5qwGYKD5vDsZXmNYaxVpzBa8sHG553JXoqWJcYajyDLYvzVBPdYI1xMDep3tVVHsIRR3NkZRx4bvD3Ie7c9Xd5zjkQQfCyr5yt8nQB7hh1bj1YFRKQ2NjQ617feWbzmeXEXZKGtmc43l5XcQoOmCE9rtmDOn8MkM9LT8HAB5/N/WxZsCaGZHlQBq6LJI09Srq9PAx3+8JibTURMZ6sGVlZA2NyeTe079m0c5XOWYh4S4qELV5EMljh0g/sBe4oDS5uNmXbUyP/opZhTePYK7NWRUIkgXShmL75Ri/7AB+0ggFLURvV/HXU3lmnJ7zsEnyjU5WQk7QEUnPngMMlr6+FSaO0UlpFxukhcj+YmDYRxaYMzaK2Uo7M3o2eLVdHrvbRPtVf/M1D/wD58+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: nikola.iva...@gmail.com [mailto:nikola.iva...@gmail.com] On Behalf Of
> Nikola Ivacic
> Sent: 20 July 2009 13:59
> To: Colm O hEigeartaigh
> Cc: wss4j-dev@ws.apache.org
> 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 <cohei...@progress.com>:
>>
>> 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:nikola.iva...@gmail.com] On Behalf Of Nikola
>> Ivacic
>> Sent: 20 July 2009 07:38
>> To: wss4j-dev@ws.apache.org
>> 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: wss4j-dev-unsubscr...@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org
> For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org
For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
