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 "Bhatra, Junaid" <jb...@rsasecurity.com> on 2007/04/26 19:03:04 UTC
Issue using SAML Tokens after upgrading to XML Security 1.4
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
Re: Issue using SAML Tokens after upgrading to XML Security 1.4
Posted by Vishal Mahajan <vm...@amberpoint.com>.
This is a known issue with apache xml-security, see
http://issues.apache.org/bugzilla/show_bug.cgi?id=40897. You might want
to report this directly to the xml-security list
(security-dev@xml.apache.org).
Vishal
Bhatra, Junaid wrote:
> 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.guaranteeThatElementInCorrectSpace()V(Unknown
> Source)
>
> at
> org.apache.xml.security.utils.ElementProxy.<init>(Lorg.w3c.dom.Element;Ljava.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.Element;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(SAMLTokenProcessor.java:53)
>
> at
> org.apache.ws.security.processor.SAMLTokenProcessor.handleToken(SAMLTokenProcessor.java:42)
>
> at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:283)
>
> at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:205)
>
> at
> org.apache.rampart.handler.WSDoAllReceiver.processBasic(WSDoAllReceiver.java:285)
>
> at
> org.apache.rampart.handler.WSDoAllReceiver.processMessage(WSDoAllReceiver.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.processHTTPPostRequest(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(StubSecurityHelper.java:223)
>
> at
> weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
>
> at
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
>
> at
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
>
> at
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3245)
>
> at
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>
> at
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
>
> at
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2003)
>
> at
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1909)
>
> at
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1359)
>
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
>
> Usage: 5
>
>
>
>
>
> Thanks,
>
> Junaid
>
>
>
Re: Issue using SAML Tokens after upgrading to XML Security 1.4
Posted by Vishal Mahajan <vm...@amberpoint.com>.
This is a known issue with apache xml-security, see
http://issues.apache.org/bugzilla/show_bug.cgi?id=40897. You might want
to report this directly to the xml-security list
(security-dev@xml.apache.org).
Vishal
Bhatra, Junaid wrote:
> 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.guaranteeThatElementInCorrectSpace()V(Unknown
> Source)
>
> at
> org.apache.xml.security.utils.ElementProxy.<init>(Lorg.w3c.dom.Element;Ljava.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.Element;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(SAMLTokenProcessor.java:53)
>
> at
> org.apache.ws.security.processor.SAMLTokenProcessor.handleToken(SAMLTokenProcessor.java:42)
>
> at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:283)
>
> at
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:205)
>
> at
> org.apache.rampart.handler.WSDoAllReceiver.processBasic(WSDoAllReceiver.java:285)
>
> at
> org.apache.rampart.handler.WSDoAllReceiver.processMessage(WSDoAllReceiver.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.processHTTPPostRequest(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(StubSecurityHelper.java:223)
>
> at
> weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
>
> at
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
>
> at
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
>
> at
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3245)
>
> at
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>
> at
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
>
> at
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2003)
>
> at
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1909)
>
> at
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1359)
>
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
>
> Usage: 5
>
>
>
>
>
> Thanks,
>
> Junaid
>
>
>