ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Redundant names space removal when Serializing - AXIOM
Date Wed, 23 Nov 2011 22:40:53 GMT
I think that by looking at the specs it is pretty clear that there is
no way a signature can be invalidated by the removal (or addition) of
a redundant namespace declaration. Here is why:
(1) Section 5.4 of the XPath 1.0 spec makes it clear that the
namespace nodes in the XPath data model don't represent namespace
declarations, but the namespaces in scope on their parent element.
This implies that the XPath data model for a given document is
invariant with respect to the removal or addition of redundant
namespace declarations in that document (in contrast to what has been
said earlier in this thread).

(2) XML C14N specifies that the input of the canonicalization is an
XPath node-set (if it is not an octet stream). Because of (1) that
means that the output of the canonicalization doesn't depend on the
presence or absence of redundant namespace declarations in the
document from which the XPath node-set has been built. Note that this
remains unchanged in the exclusive C14N spec.
(3) The XML Signature spec relies on C14N to compute the digest. If
the signature refers to an element, then the node-set on which C14N is
applied corresponds to the subtree determined by that element (modulo
comment nodes). However, the nodes in that node-set are still built
from the document containing the element (and not from a document
obtained by extracting that element). In particular an element in that
node-set may have a namespace node for a namespace declared on an
ancestor of the signed element. Because of (2) this implies that the
signature doesn't change when removing (or adding) a redundant
namespace declaration.
As far as I can see, none of the specs speak about extracting or
detaching the element to compute its signature. However, in practice,
instead of executing the XML Signature processing model literally, it
is indeed possible to get the same result by extracting the element
and computing the signature based on that. Both exclusive C14N and
SAML rely on this fact and this is what Prabath refers to. However,
this only works if it is done correctly, namely in such a way that the
namespace context of the element is preserved, which is basically what
Aleksander explained in his post. The only addition is that with
exclusive C14N one can omit prefixes that are neither in the
InclusiveNamespaces PrefixList nor used in the element or one of its
descendants.
Putting it all together:* The fact that the back-end service rejects
the signature after removing the redundant xsi declaration indicates
that it doesn't properly validate the signature.* A likely explanation
is that it detaches the SAML assertion but fails to preserve the
required namespace context in that operation.
Andreas
On Wed, Nov 23, 2011 at 15:06, Prabath Siriwardena <prabath@wso2.com> wrote:
> As per the WS-Trust / SAML token profile - the Assertion element is self
> contained..
> This is how it works.. The client talks to STS and in the RSTR returned from
> the STS - it adds the Assertion element - which is self contained and with
> an enveloped signature signed by the STS.
> Now client stores this Assertion element locally - detached from the SOAP
> envelope and uses it either as a ProtectionToken or as a SupportingToken
> when talking the service provider.
> Then service provider once again validates the signature of the Assertion
> element to make sure it comes from a trusted STS.
> The canonicalization method used in Charith's case
> is http://www.w3.org/2001/10/xml-exc-c14n# - but I don't think the issue is
> related to the canonicalization..
> Thanks & regards,
> -Prabath
>
> On Wed, Nov 23, 2011 at 5:02 PM, Andreas Veithen <andreas.veithen@gmail.com>
> wrote:
>>
>> "Assertion element is built, signed and added in to the SOAP Envelope."
>>
>> That would mean that in order to validate the signature, one detaches
>> the assertion, calculates the signature and compares it with the
>> received signature. Where in the specs is this written?
>>
>> I think that section 7.3 of the xmldsig spec [1] says something
>> different, namely that the signature is always calculated in the
>> context of the complete document (i.e. without detaching the element),
>> but that one can get an equivalent result using one of the following
>> strategies:
>>
>> [quote]
>> 1. Rely upon the enveloping application to properly divorce its body
>> (the signature payload) from the context (the envelope) before the
>> signature is validated. Or,
>> 2. Use a canonicalization method that "repels/excludes" instead of
>> "attracts" ancestor context. [XML-C14N] purposefully attracts such
>> context."
>> [/quote]
>>
>> So, either there is something in the WS-Security or SAML specs
>> corresponding to item 1 (and then I want to see that), or what you are
>> saying amounts to the assumption that a particular canonicalization
>> method is used. Actually, what is the canonicalization method used in
>> Charith's case?
>>
>> Andreas
>>
>> [1] http://www.w3.org/TR/xmldsig-core/#sec-NamespaceContext
>>
>> On Wed, Nov 23, 2011 at 10:25, Prabath Siriwardena <prabath@wso2.com>
>> wrote:
>> >
>> > Hi Andreas;
>> > On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen
>> > <andreas.veithen@gmail.com>
>> > wrote:
>> >>
>> >> Prabath,
>> >>
>> >> This is yet another assertion that is not based on any kind of proper
>> >> argumentation. "not aware of the duplicate namespaces present in
>> >> parent element" would imply that WS-Security requires an
>> >> implementation to detach the element being signed and to forget the
>> >> namespace context associated to its parent element. Where is this
>> >> written?
>> >>
>> >
>> > The SAML Assertion uses Enveloped Signature - not the detached signature
>> > -
>> > which is covered under the SAML token profile - so, in this case.
>> > Assertion
>> > element is built, signed and added in to the SOAP Envelope..
>> > Thanks & regards,
>> > -Prabath
>> >
>> >>
>> >> Andreas
>> >>
>> >> On Wed, Nov 23, 2011 at 08:49, Prabath Siriwardena <prabath@wso2.com>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana
>> >> > <sanjiva@opensource.lk>
>> >> > wrote:
>> >> >>
>> >> >> Oh I wasn't try to divert stuff with you dude .. I definitely know
>> >> >> you
>> >> >> well enough for that.
>> >> >> Neither am I at all proposing default behavior - I think the only
>> >> >> "fix"
>> >> >> is
>> >> >> to have an option to serialize without losing anything. I don't
see
>> >> >> any
>> >> >> issue with that.
>> >> >
>> >> > I doubt this specific issue is directly related to canonicalization
-
>> >> > when
>> >> > we sign the message [in this case SAML Assertion] - only the
>> >> > Assertion
>> >> > element is canonicalized.. and not aware of the duplicate namespaces
>> >> > present
>> >> > in parent element.. In Charith's case the Assertion element present
>> >> > is
>> >> > canonicalized properly - but the issue is the duplicate namespace
>> >> > being
>> >> > added to Envelope..
>> >> > So - if we are removing duplicate namespaces as a way of optimizing,
>> >> > +1
>> >> > for
>> >> > making it optional..
>> >> > Thanks & regards,
>> >> > -Prabath
>> >> >
>> >> >>
>> >> >> On the specific issue- I'm looking for clarification .. I've started
>> >> >> a
>> >> >> thread with James Clark (who wrote the XPath spec and helped with
>> >> >> the
>> >> >> NS
>> >> >> spec and knows a lot of this stuff much better than I ever will)
to
>> >> >> get
>> >> >> it
>> >> >> clarified. Will report back shortly (and I'm usually wrong with
him
>> >> >> so
>> >> >> I'm
>> >> >> expecting there's some flaw in my logic / reading of the spec).
>> >> >> Sanjiva.
>> >> >>
>> >> >> On Wed, Nov 23, 2011 at 12:52 AM, Andreas Veithen
>> >> >> <andreas.veithen@gmail.com> wrote:
>> >> >>>
>> >> >>> Sanjiva,
>> >> >>>
>> >> >>> I think that you know me well enough by now to know that neither
>> >> >>> authority arguments nor diversions work with me. You made an
>> >> >>> assertion
>> >> >>> and I challenge you to prove it. You are not going to get away
that
>> >> >>> easily ;-)
>> >> >>>
>> >> >>> Note that I think that removing a redundant namespace declaration
>> >> >>> may
>> >> >>> indeed cause problems with canonicalization, but only if several
>> >> >>> conditions are met. I would like to understand when this occurs
and
>> >> >>> if
>> >> >>> the case that Charith encountered is an example of this or
if the
>> >> >>> issue is caused by a broken client, a broken back-end service
or an
>> >> >>> incorrect security policy.
>> >> >>>
>> >> >>> To answer your question: yes, removing redundant namespace
>> >> >>> declarations has been the default behavior in Axiom for a long
time
>> >> >>> (even before I started to work on Axiom) and it should stay
the
>> >> >>> default behavior. There are a couple of reasons for that. I
will
>> >> >>> explain them to you once you come up with a correct argument
>> >> >>> supporting your point of view. We can then confront these arguments
>> >> >>> to
>> >> >>> see what is the correct solution for the problem.
>> >> >>>
>> >> >>> Andreas
>> >> >>>
>> >> >>> On Tue, Nov 22, 2011 at 18:21, Sanjiva Weerawarana
>> >> >>> <sanjiva@opensource.lk> wrote:
>> >> >>> > Andreas independent of the C14N aspect, with Axiom if
you read a
>> >> >>> > doc
>> >> >>> > and
>> >> >>> > write it back out the XML will be different. Is that what
we want
>> >> >>> > the
>> >> >>> > default behavior to be?
>> >> >>> > The spec has a convoluted set of guidelines on when its
ok to
>> >> >>> > drop
>> >> >>> > stuff ..
>> >> >>> > I will try to give you a concrete example but I think
the above
>> >> >>> > question is
>> >> >>> > far simpler.
>> >> >>> > Sanjiva.
>> >> >>> >
>> >> >>> > On Tue, Nov 22, 2011 at 6:36 PM, Andreas Veithen
>> >> >>> > <andreas.veithen@gmail.com>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Well, the problem is that that specification actually
>> >> >>> >> contradicts
>> >> >>> >> what
>> >> >>> >> you are saying. You can find the relevant quote in
section 2.1
>> >> >>> >> "Data
>> >> >>> >> Model":
>> >> >>> >>
>> >> >>> >> "An element E has namespace nodes that represent its
namespace
>> >> >>> >> declarations as well as any namespace declarations
made by its
>> >> >>> >> ancestors that have not been overridden in E's declarations,
the
>> >> >>> >> default namespace if it is non-empty, and the declaration
of the
>> >> >>> >> prefix xml."
>> >> >>> >>
>> >> >>> >> Removing a redundant namespace declaration therefore
doesn't
>> >> >>> >> change
>> >> >>> >> the data model because that declaration is "restored"
by virtue
>> >> >>> >> of
>> >> >>> >> the
>> >> >>> >> second part of that definition. Therefore the output
of the
>> >> >>> >> canonicalization (and hence the signature) doesn't
change.
>> >> >>> >>
>> >> >>> >> Andreas
>> >> >>> >>
>> >> >>> >> Note: the superfluous namespace declarations implied
by this
>> >> >>> >> definition are eliminated by the following rule specified
in
>> >> >>> >> section
>> >> >>> >> 2.3 "Processing Model":
>> >> >>> >>
>> >> >>> >> "A namespace node N is ignored if the nearest ancestor
element
>> >> >>> >> of
>> >> >>> >> the
>> >> >>> >> node's parent element that is in the node-set has
a namespace
>> >> >>> >> node
>> >> >>> >> in
>> >> >>> >> the node-set with the same local name and value as
N. Otherwise,
>> >> >>> >> process the namespace node N in the same way as an
attribute
>> >> >>> >> node,
>> >> >>> >> except assign the local name xmlns to the default
namespace node
>> >> >>> >> if
>> >> >>> >> it
>> >> >>> >> exists (in XPath, the default namespace node has an
empty URI
>> >> >>> >> and
>> >> >>> >> local name)."
>> >> >>> >>
>> >> >>> >> On Tue, Nov 22, 2011 at 13:31, Sanjiva Weerawarana
>> >> >>> >> <sanjiva@opensource.lk> wrote:
>> >> >>> >> > http://www.w3.org/TR/xml-c14n
>> >> >>> >> >
>> >> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>> >> >>> >> > <sanjiva@opensource.lk>
>> >> >>> >> > wrote:
>> >> >>> >> >>
>> >> >>> >> >> Please look at the C14N spec.
>> >> >>> >> >>
>> >> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas
Veithen
>> >> >>> >> >> <andreas.veithen@gmail.com> wrote:
>> >> >>> >> >>>
>> >> >>> >> >>> Sanjiva,
>> >> >>> >> >>>
>> >> >>> >> >>> Can you substantiate these claims by
references to the spec
>> >> >>> >> >>> or
>> >> >>> >> >>> concrete examples?
>> >> >>> >> >>>
>> >> >>> >> >>> Andreas
>> >> >>> >> >>>
>> >> >>> >> >>> On Tue, Nov 22, 2011 at 03:51, Sanjiva
Weerawarana
>> >> >>> >> >>> <sanjiva@opensource.lk> wrote:
>> >> >>> >> >>> > Thanks for the clear writeup Andreas.
>> >> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM,
Andreas Veithen
>> >> >>> >> >>> > <andreas.veithen@gmail.com>
wrote:
>> >> >>> >> >>> >>
>> >> >>> >> >>> >> removal of redundant namespace
declarations? I don't know
>> >> >>> >> >>> >> the
>> >> >>> >> >>> >> C14N
>> >> >>> >> >>> >> specs well enough to answer
that question, but I've seen
>> >> >>> >> >>> >> that
>> >> >>> >> >>> >> these
>> >> >>> >> >>> >> specs make provisions to preserve
the namespace context
>> >> >>> >> >>> >> of
>> >> >>> >> >>> >> the
>> >> >>> >> >>> >> element
>> >> >>> >> >>> >> and also define an algorithm
to remove redundant
>> >> >>> >> >>> >> namespace
>> >> >>> >> >>> >> declarations (search for "superfluous"
or "unnecessary"
>> >> >>> >> >>> >> namespace
>> >> >>> >> >>> >> declarations through the specs).
>> >> >>> >> >>> >
>> >> >>> >> >>> > Simple answer is that yes the spec
is sensitive to any
>> >> >>> >> >>> > nodes
>> >> >>> >> >>> > being
>> >> >>> >> >>> > removed,
>> >> >>> >> >>> > including seemingly redundant namespace
nodes. As Alek
>> >> >>> >> >>> > noted,
>> >> >>> >> >>> > with
>> >> >>> >> >>> > the
>> >> >>> >> >>> > advent of XPath, its now possible
for a namespace
>> >> >>> >> >>> > declaration
>> >> >>> >> >>> > that
>> >> >>> >> >>> > looks
>> >> >>> >> >>> > redundant to an XML parser to actually
be required.
>> >> >>> >> >>> > However
>> >> >>> >> >>> > this
>> >> >>> >> >>> > case
>> >> >>> >> >>> > is
>> >> >>> >> >>> > simpler- the element is signed and
removing the node
>> >> >>> >> >>> > breaks
>> >> >>> >> >>> > the
>> >> >>> >> >>> > signature.
>> >> >>> >> >>> > I think we need to have a way to
say "don't mess with the
>> >> >>> >> >>> > XML
>> >> >>> >> >>> > serialization
>> >> >>> >> >>> > AT ALL" .. that is what we want
in the case of Synapse is
>> >> >>> >> >>> > not
>> >> >>> >> >>> > just
>> >> >>> >> >>> > an
>> >> >>> >> >>> > infoset preserving serialization
but rather the EXACT
>> >> >>> >> >>> > serialization.
>> >> >>> >> >>> > Sanjiva.
>> >> >>> >> >>> > --
>> >> >>> >> >>> > Sanjiva Weerawarana, Ph.D.
>> >> >>> >> >>> > Founder, Director & Chief Scientist;
Lanka Software
>> >> >>> >> >>> > Foundation;
>> >> >>> >> >>> > http://www.opensource.lk/
>> >> >>> >> >>> > Founder, Chairman & CEO; WSO2;
http://wso2.com/
>> >> >>> >> >>> > Founder & Director; Thinkcube
Systems;
>> >> >>> >> >>> > http://www.thinkcube.com/
>> >> >>> >> >>> > Member; Apache Software Foundation;
http://www.apache.org/
>> >> >>> >> >>> > Visiting Lecturer; University of
Moratuwa;
>> >> >>> >> >>> > http://www.cse.mrt.ac.lk/
>> >> >>> >> >>> >
>> >> >>> >> >>> > Blog: http://sanjiva.weerawarana.org/
>> >> >>> >> >>> >
>> >> >>> >> >>>
>> >> >>> >> >>>
>> >> >>> >> >>>
>> >> >>> >> >>>
>> >> >>> >> >>> ---------------------------------------------------------------------
>> >> >>> >> >>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >> >>> >> >>> For additional commands, e-mail: dev-help@ws.apache.org
>> >> >>> >> >>>
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> --
>> >> >>> >> >> Sanjiva Weerawarana, Ph.D.
>> >> >>> >> >> Founder, Director & Chief Scientist;
Lanka Software
>> >> >>> >> >> Foundation;
>> >> >>> >> >> http://www.opensource.lk/
>> >> >>> >> >> Founder, Chairman & CEO; WSO2; http://wso2.com/
>> >> >>> >> >> Founder & Director; Thinkcube Systems;
>> >> >>> >> >> http://www.thinkcube.com/
>> >> >>> >> >> Member; Apache Software Foundation; http://www.apache.org/
>> >> >>> >> >> Visiting Lecturer; University of Moratuwa;
>> >> >>> >> >> http://www.cse.mrt.ac.lk/
>> >> >>> >> >>
>> >> >>> >> >> Blog: http://sanjiva.weerawarana.org/
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> > --
>> >> >>> >> > Sanjiva Weerawarana, Ph.D.
>> >> >>> >> > Founder, Director & Chief Scientist; Lanka
Software
>> >> >>> >> > Foundation;
>> >> >>> >> > http://www.opensource.lk/
>> >> >>> >> > Founder, Chairman & CEO; WSO2; http://wso2.com/
>> >> >>> >> > Founder & Director; Thinkcube Systems;
>> >> >>> >> > http://www.thinkcube.com/
>> >> >>> >> > Member; Apache Software Foundation; http://www.apache.org/
>> >> >>> >> > Visiting Lecturer; University of Moratuwa;
>> >> >>> >> > http://www.cse.mrt.ac.lk/
>> >> >>> >> >
>> >> >>> >> > Blog: http://sanjiva.weerawarana.org/
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> ---------------------------------------------------------------------
>> >> >>> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >> >>> >> For additional commands, e-mail: dev-help@ws.apache.org
>> >> >>> >>
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > --
>> >> >>> > Sanjiva Weerawarana, Ph.D.
>> >> >>> > Founder, Director & Chief Scientist; Lanka Software
Foundation;
>> >> >>> > http://www.opensource.lk/
>> >> >>> > Founder, Chairman & CEO; WSO2; http://wso2.com/
>> >> >>> > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/
>> >> >>> > Member; Apache Software Foundation; http://www.apache.org/
>> >> >>> > Visiting Lecturer; University of Moratuwa;
>> >> >>> > http://www.cse.mrt.ac.lk/
>> >> >>> >
>> >> >>> > Blog: http://sanjiva.weerawarana.org/
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >> >>> For additional commands, e-mail: dev-help@ws.apache.org
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Sanjiva Weerawarana, Ph.D.
>> >> >> Founder, Director & Chief Scientist; Lanka Software Foundation;
>> >> >> http://www.opensource.lk/
>> >> >> Founder, Chairman & CEO; WSO2; http://wso2.com/
>> >> >> Founder & Director; Thinkcube Systems; http://www.thinkcube.com/
>> >> >> Member; Apache Software Foundation; http://www.apache.org/
>> >> >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>> >> >>
>> >> >> Blog: http://sanjiva.weerawarana.org/
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Thanks & Regards,
>> >> > Prabath
>> >> >
>> >> > http://blog.facilelogin.com
>> >> > http://RampartFAQ.com
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: dev-help@ws.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Thanks & Regards,
>> > Prabath
>> >
>> > http://blog.facilelogin.com
>> > http://RampartFAQ.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: dev-help@ws.apache.org
>>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message