axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart Jensen" <>
Subject Re: AXIS altering XML causing signatures to not validate.
Date Tue, 26 Oct 2004 18:50:32 GMT
I was trying to get a more general answer about this issue.
Is it generally acceptable to AXIS users/developers that XML be
modified during serilization?
But, if you want my specific example, here it is:
If you create a SOAPBodyElement with the following XML:
<soapenv:Body wsu:id="id-23412344"
<somepfx:SomeTag id="e0sdoaeckrpd"  xmlns="ns:uri:one"
and then pass that SOAPBodyElement to the Call.invoke(Object[]) method
as a member of the Object[] parameter.  Then the XML that is sent by
AXIS is the following:
<soapenv:Body wsu:id="id-23412344"
<SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
Note that the only difference is that the namespace prefix "somepfx"
has been removed from the tag "SomeTag".
Now I realize that setting the default namespace AND defining a
namespace prefix for the same namespace is redundant, but there exists a
company, that we need to interoperate with, that does exactly that.
Stuart Jensen

>>> 10/26/04 11:23 AM >>>


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 <>
> It appears that there has been some discussion on this board about
> instances where XML is altered during serialization and thus causing
> subsequent signature validations to fail.  The responses to these
> appear to have focused on getting a specific XML to work. However, I
> not seen any comments on the problem in general. 
> After debugging into the AXIS serialization code, it is apparent that
> 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
> changing XML is a manner that is not compatible with the latest C14N
> (Meaning the C14N code will not "mask" the changes.)   If you are
> 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
> "get the XML right." Meaning, setup the namespace declarations and
> such that AXIS does not change them.  To me this seems like an
> solution.  We interoperate with companies that do not use AXIS, and
> signed requests may/will have XML in all sorts of configurations. We
> 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,
> by AXIS, on the receiving side, then I suppose we could parse it
> 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
> signature and cannot be changed. However, AXIS XML serialization
> 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
> outputContext.registerPrefixForURI(prefix, namespaceURI); 
> These prefixes are used when the SerializationContext's 
> public String getPrefixForURI(String uri, String defaultPrefix,
> 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.
> 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
>         // return "" as the prefix to favor defaults where possible.
>         if (!noDefault && currentDefaultNS > 0 &&
stack[currentDefaultNS] !=
> null &&
>                 namespaceURI ==
>         {
>  // 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