You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by Nikola Ivačič <ni...@amis.net> on 2009/07/20 08:38:19 UTC
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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: Interoperability problem with JBoss native stack
Posted by Colm O hEigeartaigh <co...@progress.com>.
Thanks Nikola, I've just merged the fix.
Colm.
-----Original Message-----
From: nikola.ivacic@gmail.com [mailto:nikola.ivacic@gmail.com] On Behalf Of Nikola Ivacic
Sent: 22 July 2009 15:47
To: Daniel Kulp
Cc: wss4j-dev@ws.apache.org; 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 <dk...@apache.org>:
>
> 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 <co...@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 =
>> > "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: nikola.ivacic@gmail.com [mailto:nikola.ivacic@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 <co...@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.ivacic@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-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Interoperability problem with JBoss native stack
Posted by Nikola Ivačič <ni...@amis.net>.
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 <dk...@apache.org>:
>
> 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 <co...@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 =
>> > "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: nikola.ivacic@gmail.com [mailto:nikola.ivacic@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 <co...@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.ivacic@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-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Interoperability problem with JBoss native stack
Posted by Daniel Kulp <dk...@apache.org>.
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 <co...@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 =
> > "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: nikola.ivacic@gmail.com [mailto:nikola.ivacic@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 <co...@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.ivacic@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-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Interoperability problem with JBoss native stack
Posted by Nikola Ivačič <ni...@amis.net>.
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 <co...@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.ivacic@gmail.com [mailto:nikola.ivacic@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 <co...@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.ivacic@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-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: Interoperability problem with JBoss native stack
Posted by Colm O hEigeartaigh <co...@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.ivacic@gmail.com [mailto:nikola.ivacic@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 <co...@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.ivacic@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-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Interoperability problem with JBoss native stack
Posted by Nikola Ivačič <ni...@amis.net>.
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 <co...@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.ivacic@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-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
Re: Interoperability problem with JBoss native stack
Posted by Nikola Ivačič <ni...@amis.net>.
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
RE: Interoperability problem with JBoss native stack
Posted by Colm O hEigeartaigh <co...@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.ivacic@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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org