axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart Jensen" <SJEN...@novell.com>
Subject AXIS altering XML causing signatures to not validate.
Date Tue, 26 Oct 2004 16:05:34 GMT
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
sjensen@novell.com
 
=======================================
 
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 NSStack.java:
 
    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 DeSerializationContext.java (on the receiving side)
also trys to play the same game.
 

Mime
View raw message