I have attached another instance of this string comparison problem that
was reported on wss4j list sometime back. The work-around is of course
to explicitly make sure that all standard namespace strings are interned
before messages are parsed.
Vishal
on 11/08/2007 8:16 PM Sean Mullan wrote:
The exception is thrown by the following method in ElementProxy:
public void guaranteeThatElementInCorrectSpace()
throws XMLSecurityException {
String localnameSHOULDBE = this.getBaseLocalName();
String namespaceSHOULDBE = this.getBaseNamespace();
String localnameIS = this._constructionElement.getLocalName();
String namespaceIS = this._constructionElement.getNamespaceURI();
if ((namespaceSHOULDBE!=namespaceIS) ||
!localnameSHOULDBE.equals(localnameIS) ) {
Object exArgs[] = { namespaceIS +":"+ localnameIS,
namespaceSHOULDBE +":"+ localnameSHOULDBE};
throw new XMLSecurityException("xml.WrongElement", exArgs);
}
}
It sounds like the namespaces, though equal, are not the same object,
thus the test is failing. Comparing by reference is done for
performance reasons, since most XML parsers intern the namespace Strings.
There has been some discussion about this issue. What XML parser are
you using? See http://issues.apache.org/bugzilla/show_bug.cgi?id=40897
--Sean
[EMAIL PROTECTED] wrote:
Hi,
I've got this strange little problem.
When I encrypt a org.w3c.Document and decrypt it on the same host,
everything is fine. When I send it over the network, the receiving
host throws an
org.apache.xml.security.encryption.XMLEncryptionException. The
interesting part of the stack trace is this:
Caused by: org.apache.xml.security.encryption.XMLEncryptionException:
No message with ID "Error loading Key Info" found in resource bundle
"org/apache/xml/security/resource/xmlsecurity". Original Exception
was a org.apache.xml.security.exceptions.XMLSecurityException and
message Cannot create a http://www.w3.org/2000/09/xmldsig#:KeyInfo
from a http://www.w3.org/2000/09/xmldsig#:KeyInfo element
Original Exception was
org.apache.xml.security.exceptions.XMLSecurityException: Cannot
create a http://www.w3.org/2000/09/xmldsig#:KeyInfo from a
http://www.w3.org/2000/09/xmldsig#:KeyInfo element
But here's the thing: When I write out the sent and received messages
to an XML file, and diff them, I find that they are exactly the same.
To the character. Surely I miss something simple. Do I need to
normalise before decrpytion? But why should that be necessary as I
use Java serialisation and the Document objects should be the same on
byte level?
The encryption I use is AES-128-Keywrap + AES.
Thanks for any pointers!
Here's the stack trace - I've marked the interesting part:
PDPA1Control: Sender in my domain, using symmetric cryptography. Key
for bob.
Decryption of message failed, but key was OK. Aborting.
NotRecoverableException reason: Decryption of message failed, but key
was OK.
This is the stack trace:
NotRecoverableException caught by NodeControl - this should really
not happen.
tue.pdp.cryptography.DecryptionFailedException: Decryption of message
failed.
at
tue.pdp.pdpa1.PDPA1Control.decryptAndVerify(PDPA1Control.java:368)
at
tue.pdp.handlers.PDPA1DASHandler.processMessage(PDPA1DASHandler.java:84)
at tue.pdp.handlers.PDPCHandler.processMessage(PDPCHandler.java:63)
at
tue.pdp.handlers.MessageHandler.processMessage(MessageHandler.java:37)
at tue.p2pdomain.NodeControl.callback(NodeControl.java:125)
at
tue.pdp.connectors.PastryConnector.callbackControl(PastryConnector.java:66)
at
tue.pdp.connectors.PastryConnector.deliver(PastryConnector.java:116)
at
rice.pastry.commonapi.PastryEndpoint.receiveMessage(PastryEndpoint.java:471)
at
rice.pastry.messaging.MessageDispatch.dispatchMessage(MessageDispatch.java:146)
at rice.pastry.PastryNode.receiveMessage(PastryNode.java:366)
at
rice.pastry.standard.StandardRouter.receiveRouteMessage(StandardRouter.java:185)
at rice.pastry.standard.StandardRouter.route(StandardRouter.java:84)
at
rice.pastry.standard.StandardRouter.receiveMessage(StandardRouter.java:76)
at
rice.pastry.client.PastryAppl.receiveMessageInternal(PastryAppl.java:183)
at
rice.pastry.messaging.MessageDispatch.dispatchMessage(MessageDispatch.java:167)
at rice.pastry.PastryNode.receiveMessage(PastryNode.java:370)
at rice.pastry.socket.SocketManager.receive(SocketManager.java:513)
at rice.pastry.socket.SocketManager.read(SocketManager.java:340)
at
rice.selector.SelectorManager.doSelections(SelectorManager.java:387)
at rice.selector.SelectorManager.run(SelectorManager.java:253)
===> interesting part here:
Caused by: org.apache.xml.security.encryption.XMLEncryptionException:
No message with ID "Error loading Key Info" found in resource bundle
"org/apache/xml/security/resource/xmlsecurity". Original Exception
was a org.apache.xml.security.exceptions.XMLSecurityException and
message Cannot create a http://www.w3.org/2000/09/xmldsig#:KeyInfo
from a http://www.w3.org/2000/09/xmldsig#:KeyInfo element
Original Exception was
org.apache.xml.security.exceptions.XMLSecurityException: Cannot
create a http://www.w3.org/2000/09/xmldsig#:KeyInfo from a
http://www.w3.org/2000/09/xmldsig#:KeyInfo element
at
org.apache.xml.security.encryption.XMLCipher$Factory.newEncryptedData(Unknown
Source)
at
org.apache.xml.security.encryption.XMLCipher.loadEncryptedData(Unknown
Source)
at
tue.pdp.cryptography.PDPCryptoOperator.symDecrypt(PDPCryptoOperator.java:296)
at
tue.pdp.pdpa1.PDPA1Control.decryptAndVerify(PDPA1Control.java:366)
... 19 more
--- Begin Message ---
Hi,
I'm trying to develop a simple Web Service that consumes SAML Tokens in
the WS-Security header using Axis2 / Rampart / WSS4J trunk (maybe about
a few weeks old). I've run into an issue on the server side after
upgrading to Apache XML Security 1.4.
I did some digging around and apparently in XML Security 1.4, code
changes were made all over the place to check for namespaceURI String
equality using == instead of equals(), with the assumption that
namespace URI Strings would be interned. This is causing weird errors
during Signature validation on the token, as you can see from the
stack-trace below. I noticed that the DOM implementation of AXIOM does
not yet intern the namespaceURI Strings. This issue does not occur using
XML Security 1.3, but we really would like to upgrade to 1.4 in order to
resolve some other errors with 1.3.
How should this be resolved? Does it require changes to AXIOM or Rampart
/ WSS4J? Has this been fixed in the latest AXIOM or Rampart / WSS4J
trunk? I would really appreciate an answer on this. I have attached the
stack-trace below:
Caused by: org.apache.xml.security.exceptions.XMLSecurityException:
Cannot create a http://www.w3.org/2000/09/xmldsig#:Signature from a
http://www.w3.org/2000/09/xmldsig#:Signature element
at
org.apache.xml.security.utils.ElementProxy.guaranteeThatElementInCorrect
Space()V(Unknown Source)
at
org.apache.xml.security.utils.ElementProxy.<init>(Lorg.w3c.dom.Element;L
java.lang.String;)V(Unknown Source)
at
org.apache.xml.security.utils.SignatureElementProxy.<init>(Lorg.w3c.dom.
Element;Ljava.lang.String;)V(Unknown Source)
at
org.apache.xml.security.signature.XMLSignature.<init>(Lorg.w3c.dom.Eleme
nt;Ljava.lang.String;)V(Unknown Source)
at
org.opensaml.SAMLSignedObject.fromDOM(Lorg.w3c.dom.Element;)V(Unknown
Source)
at
org.opensaml.SAMLAssertion.fromDOM(Lorg.w3c.dom.Element;)V(Unknown
Source)
at
org.opensaml.SAMLAssertion.<init>(Lorg.w3c.dom.Element;)V(Unknown
Source)
at
org.apache.ws.security.processor.SAMLTokenProcessor.handleSAMLToken(SAML
TokenProcessor.java:53)
at
org.apache.ws.security.processor.SAMLTokenProcessor.handleToken(SAMLToke
nProcessor.java:42)
at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurity
Engine.java:283)
at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurity
Engine.java:205)
at
org.apache.rampart.handler.WSDoAllReceiver.processBasic(WSDoAllReceiver.
java:285)
at
org.apache.rampart.handler.WSDoAllReceiver.processMessage(WSDoAllReceive
r.java:91)
at
org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:72)
at org.apache.axis2.engine.Phase.invoke(Phase.java:383)
at
org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:197)
at
org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:125)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReques
t(HTTPTransportUtils.java:279)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:117)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(St
ubSecurityHelper.java:223)
at
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityH
elper.java:125)
at
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:2
83)
at
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:1
75)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.r
un(WebAppServletContext.java:3245)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSu
bject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121
)
at
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServ
letContext.java:2003)
at
weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletCont
ext.java:1909)
at
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java
:1359)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
Usage: 5
Thanks,
Junaid
--- End Message ---
