axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: AXIS altering XML causing signatures to not validate.
Date Tue, 26 Oct 2004 17:23:51 GMT

We do all kinds of WS-Security (xmlenc,xmldsig,c14n etc) stuff in
WSS4J using Axis (with little problems). So PLEASE lead the discussion
by stating a specific problem with a test case.


On Tue, 26 Oct 2004 10:05:34 -0600, Stuart Jensen <> wrote:
> It appears that there has been some discussion on this board about specific
> instances where XML is altered during serialization and thus causing
> subsequent signature validations to fail.  The responses to these instances
> appear to have focused on getting a specific XML to work. However, I have
> not seen any comments on the problem in general. 
> After debugging into the AXIS serialization code, it is apparent that the
> developers went to great lengths to "optimize" the XML produced by
> serialization. Were XML signatures kept in mind during the development of
> the AXIS De/Serializers?  From my investigations, I conclude that AXIS is
> changing XML is a manner that is not compatible with the latest C14N specs.
> (Meaning the C14N code will not "mask" the changes.)   If you are interested
> in a more detailed discussion of what I found see below. 
> Is it the position of the AXIS development community that such XML
> modifications are acceptable/desirable?  Given the troubles it is causing us
> with our signature validations, I hope it is considered a bug and that it
> can be addressed in this upcomming release. 
> I have seen several instances where the "solution" to the problem was to
> "get the XML right." Meaning, setup the namespace declarations and prefixes
> such that AXIS does not change them.  To me this seems like an invalid
> solution.  We interoperate with companies that do not use AXIS, and their
> signed requests may/will have XML in all sorts of configurations. We cannot
> control what is sent to us.  And we must be able to validate their
> signatures.  I suppose that on the sending side we could tweak our XML so
> that AXIS can handle it, but on the receiving side I do not see how to get
> around this. 
> If there were a way for an AXIS handler to get at the raw XML, unserialized
> by AXIS, on the receiving side, then I suppose we could parse it ourselves
> and perform the validations on that.  Just seems like a big waste of
> processing time. 
> Does anyone have any comments on this problem? 
> Thanks for your time, 
> Stuart Jensen 
> ======================================= 
> The latest C14N specs state that the namespace prefixes are part of the
> signature and cannot be changed. However, AXIS XML serialization removes
> redundant namespace prefixes.  The code path inwhich this happens is
> detailed below: 
> On the sending side: When Call.invoke() is called it eventually gets down to
> where it serializes the SOAPBodyElements
>  into XML that it ends up sending in the request. Since every
> SOAPBodyElement is an instance of an MessageElement the
>  serialization executes through MessaeElement's 
> protected void outputImpl(SerializationContext outputContext) throws
> Exception 
> which registers the current prefix with the SerializationContext by calling 
> outputContext.registerPrefixForURI(prefix, namespaceURI); 
> These prefixes are used when the SerializationContext's 
> public String getPrefixForURI(String uri, String defaultPrefix, boolean
> attribute) 
> is called.  This method uses an NSStack object to keep track of what
> namespaces are currently in play.  The problem is
> that this method has code that checks the current default namespace URI and
> if it is the same as the namespace currently
> being requested, then it returns an "empty string" prefix. Effectively,
> removing the prefix from the XML. The offending code
> is in 
>     public String getPrefix(String namespaceURI, boolean noDefault) {
>         if ((namespaceURI == null) || (namespaceURI.length()==0))
>             return null;
>         // If defaults are OK, and the given NS is the current default,
>         // return "" as the prefix to favor defaults where possible.
>         if (!noDefault && currentDefaultNS > 0 && stack[currentDefaultNS]
> null &&
>                 namespaceURI == stack[currentDefaultNS].getNamespaceURI())
>         {
>  // No need to return the prefix - already in that namespace!!!
>             return "";
>         } 
> It appears that the (on the receiving side) also
> trys to play the same game. 

Davanum Srinivas -

View raw message