You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Stuart Jensen <SJ...@novell.com> on 2004/10/26 18:05:34 UTC
AXIS altering XML causing signatures to not validate.
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.
Re: AXIS altering XML causing signatures to not validate.
Posted by Davanum Srinivas <da...@gmail.com>.
Stuart,
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.
thanks,
dims
On Tue, 26 Oct 2004 10:05:34 -0600, Stuart Jensen <sj...@novell.com> 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
> 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.
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: AXIS altering XML causing signatures to not validate.
Posted by Samuel Meder <me...@mcs.anl.gov>.
See comment inline
On Tue, 2004-10-26 at 10:05 -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
> 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:
What do you mean by "the latest"? Canonical XML 1.0 says:
Unnecessary namespace declarations are not made in the canonical form.
Whether for an empty default namespace, a non-empty default namespace,
or a namespace prefix binding, the XML canonicalization method omits a
declaration if it determines that the immediate parent element in the
canonical form has an equivalent declaration in scope. The root document
element is handled specially since it has no parent element. All
namespace declarations in it are retained, except the declaration of an
empty default namespace is automatically omitted.
(http://www.w3.org/TR/2001/REC-xml-c14n-20010315#SuperfluousNSDecl)
/Sam
> 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.
>