Hi Gang, To belatedly follow up on this, I merged a fix to 1_5_x-fixes there that solves the failing test-cases for when the IdResolver can't find a SecurityTokenReference:
Author: coheigea Date: Mon May 24 11:28:48 2010 New Revision: 947604 URL: http://svn.apache.org/viewvc?rev=947604&view=rev Log: Changed the signature creation code to store SecurityTokenReference elements in WSDocInfo for retrieval in the EnvelopeIdResolver - This avoids the need for DOM traversal in certain cases. The main motivation behind this was to try to address some of the test failures caused by a suggested fix to get WSS4J working in websphere. - This does not apply to trunk as the IdResolver is not used there The namespace prefix test is still failing however. I don't see a way to get this working with your suggested change for the moment, and so I can't merge your fix. Colm. -----Original Message----- From: Yang, Gang CTR USA [mailto:[email protected]] Sent: 07 December 2009 22:21 To: Colm O hEigeartaigh; [email protected] Subject: RE: Wss4j working with WebSphere? Hi, Colm, I've just found some time in between my works to look into the failed tests. They seems to be all related to the cases of signing the security token using STR-Transform. Because in this case the Reference refers to the security token indirectly via the <SecurityTokenReference> inside the <Signature> and my change delayed the creation of the <Signature> element until the very end, the resolver failed to find the referred element in the original SOAP message. At this point, I don't have a generic solution, but a workaround that works on most cases but signing the security token. I think the root cause is still that wss4j (more accurately xml-sec) used a set of DOM objects to refer and change the <SignatureValue> and <DigestValue>, but IBM WAS changed the DOM objects dynamically. Should I create an issue in JIRA? Gang -----Original Message----- From: Colm O hEigeartaigh [mailto:[email protected]] Sent: Tuesday, November 24, 2009 12:01 PM To: Yang, Gang CTR USA; [email protected] Subject: RE: Wss4j working with WebSphere? Eclipse. I normally run tests from the command line, e.g. "mvn clean install" or "mvn test". Colm. -----Original Message----- From: Yang, Gang CTR USA [mailto:[email protected]] Sent: 24 November 2009 16:02 To: Colm O hEigeartaigh; [email protected] Subject: RE: Wss4j working with WebSphere? Hi, Colm, What's your dev env? I checked out 1_5_x-fixes branch into MyEclipse 7.5 and MyEclipse hung at "Initinalizging Java Tools" each time I restart MyEclipse. Gang -----Original Message----- From: Colm O hEigeartaigh [mailto:[email protected]] Sent: Tuesday, November 24, 2009 6:33 AM To: Yang, Gang CTR USA; [email protected] Subject: RE: Wss4j working with WebSphere? Hi Gang, If I apply your fix it breaks 5 tests, one in TestWSSecurityNew3 and 4 in TestWSSecurityNew11. Can you take a look at these tests in branches/1_5_x-fixes after applying your fix? Colm. -----Original Message----- From: Yang, Gang CTR USA [mailto:[email protected]] Sent: 18 November 2009 22:30 To: [email protected] Subject: RE: Wss4j working with WebSphere? Hi, After some debugging, I think I found why wss4j isn't working with WAS properly. The problem is caused by the way WAS's SOAP/DOM implements Node.appendChild() and Node.insertBefore() and the timing wss4j inserts the <Signature> element into the header. WAS's element insertion implementation puts the appended/inserted child in a temp area (altContent) and used the API to hide that. When the child element is actually accessed, it would put the child and its sub-tree into the normal place by "copying", which causes "new" node objects to be generated. Back to wss4j, WSSecSignature.build() calls "prependToHeader" to insert <Signature> element into the header (and doc) early and then was trying to do the signing. During the signing process, it actually accesses the <Signature> element causing WAS to copy and regenerate. This would cause the object references to the <DigestValue> and <SignatureValue> in sig (XMLSignaure) member to stale. Therefore the inserted <DigestValue> values and <SignatureValue> value are not actually inserted into the final SOAP document. I modified the code to call prependToHeader() at last after the computeSignature() call. This seems to have worked fine with WAS now. However, since I'm not an expert in wss4j and would like some one, Cole maybe?, to bless the change and pull that into the codebase if that's fine. Thanks, Gang PS: The modified WSSecSignature.build() code: public Document build(Document doc, Crypto cr, WSSecHeader secHeader) throws WSSecurityException { doDebug = log.isDebugEnabled(); if (doDebug) { log.debug("Beginning signing..."); } prepare(doc, cr, secHeader); SOAPConstants soapConstants = WSSecurityUtil.getSOAPConstants(doc.getDocumentElement()); if (parts == null) { parts = new Vector(); WSEncryptionPart encP = new WSEncryptionPart( soapConstants.getBodyQName().getLocalPart(), soapConstants.getEnvelopeURI(), "Content" ); parts.add(encP); } addReferencesToSign(parts, secHeader); // put at the end instead: // prependToHeader(secHeader); // // if we have a BST prepend it in front of the Signature according to // strict layout rules. // if (bstToken != null) { prependBSTElementToHeader(secHeader); } computeSignature(); prependToHeader(secHeader); return doc; } -----Original Message----- From: Yang, Gang CTR USA [mailto:[email protected]] Sent: Tuesday, November 17, 2009 9:31 AM To: [email protected] Subject: Wss4j working with WebSphere? Hi, Has any one used wss4j with WebSphere successfully? I'm using wss4j 1.5.8 with WAS 7.0 unsuccessfully. I'm using wss4j to build the SOAP security headers and signature using JAX-WS handlers. After the WSSSingnature.build() call without any error, the security headers were added to the SOAP message without the digest values and signature value. Has any one experienced similar behavior and has any insight? Thanks, Gang --------------------------------------------------------------------- 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]
