Bug 44874 - canonicalizer not getting intialized
Summary: canonicalizer not getting intialized
Status: RESOLVED DUPLICATE of bug 40897
Alias: None
Product: Security - Now in JIRA
Classification: Unclassified
Component: Canonicalization (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 major
Target Milestone: ---
Assignee: XML Security Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-25 08:53 UTC by Sivasankari Swaminathan
Modified: 2010-10-17 14:55 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sivasankari Swaminathan 2008-04-25 08:53:26 UTC
While engaging rampart module(1.3) for axis2(2.1.3) WSSecurity authentication, rampart internally is looking for Canonicalizer's which get initialized by classes in xmlsec.jar (version used is 1.4.1)

The initialization of canonicalizer is performed when the rampart module is engaged, and they are used during the runtime addition of WSSecurity to axis2 SOAP message.

canonicalizer and other config elements stored in the config.xml file inside the xmlsec,  xml-security-src-1_4_1\xml-security-1_4_1\src\org\apache\xml\security\resource directory is not getting initialized, because of the fact that the following condition in XMLUtils.selectNodes() does not get satisfied anytime:

if (nodeName.equals(sibling.getLocalName())
    				&& uri==sibling.getNamespaceURI()) 

As observed the object comparison uri==sibling.getNamespaceURI() will not be true any time, it must have been as a String comparison like the nodeName comparison.

After correcting it as:

if (nodeName.equals(sibling.getLocalName())
    				&& uriiequals(sibling.getNamespaceURI())) 

the config file got initialized properly and no exception was thrown by rampart.

The XMLUtils.java has other methods which has the same kind of object comparison for the uri namespace, which also needs this fix.



For Reference the Eception stacktrace:

org.apache.xml.security.c14n.InvalidCanonicalizerException: Unknown canonicalizer. No handler installed for URI http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments

      at org.apache.xml.security.c14n.Canonicalizer.<init>(Unknown Source)

      at org.apache.xml.security.c14n.Canonicalizer.getInstance(Unknown Source)

      at org.apache.xml.security.utils.XMLUtils.outputDOM(Unknown Source)

      at org.apache.rampart.util.Axis2Util.getSOAPEnvelopeFromDOMDocument(Axis2Util.java:209)

      at org.apache.rampart.handler.WSDoAllSender.processBasic(WSDoAllSender.java:218)

      at org.apache.rampart.handler.WSDoAllSender.processMessage(WSDoAllSender.java:64)

      at org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:72)

      at org.apache.axis2.engine.Phase.invoke(Phase.java:292)

      at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:212)

      at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:377)

      at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:374)

      at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)

      at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)

      at org.example.types.EcrmInRWSServiceStub.getCustInv(EcrmInRWSServiceStub.java:747)

      at org.apache.jsp.testInRresult_jsp._jspService(testInRresult_jsp.java:107)

      at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)

      at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

      at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)

      at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:315)

      at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)

      at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)

      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)

      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)

      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)

      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)

      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)

      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)

      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)

      at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)

      at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)

      at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)

      at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)

      at java.lang.Thread.run(Unknown Source)


Thanks
Shiv
Comment 1 sean.mullan 2008-04-25 13:07:30 UTC
See https://issues.apache.org/bugzilla/show_bug.cgi?id=40897 for more discussion about this issue and why XMLSec is implemented the way it is. 

In 1.4.2 there will be an  
org.apache.xml.utils.ElementChecker interface and you can implement the
guaranteeThatElementInCorrectSpace method and compare the namespaces using the
equals method.

We still need to add a mechanism to allow you to specify your own ElementChecker from an application though. Right now you would have to modify the ElementProxy source to use a different one.
Comment 2 coheigea 2010-10-17 14:55:21 UTC
This is a duplicate of Bug 40897, and is now fixed.

Colm.

*** This bug has been marked as a duplicate of bug 40897 ***