You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by Charith Wickramarachchi <ch...@gmail.com> on 2011/11/18 03:23:15 UTC
Redundant names space removal when Serializing - AXIOM
Hi devs ,
When we serialize a OMElement axiom will omit redundant namesspace
declarations by default. Is it possible to disable this behavior ?
In my case i want to keep the redundant namesspace declarations in SOAP
headers.
thanks,
Charith
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
>From what I understand, this is caused by a broken back-end service.
Here is what Charith said:
"BE services header processor incorrectly assumes that headers are
self contained so this causes an error."
Andreas
On Sun, Nov 20, 2011 at 18:42, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> "So when synapse forward them to the BE service they get omitted as they
> are defined at SOAP Envelope level."
> Maybe Synapse is not serializing the headers properly?
> Sanjiva.
>
> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen
> <an...@gmail.com> wrote:
>>
>> Axiom never produces malformed XML. Who said that??
>>
>> Andreas
>>
>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
>> <sa...@opensource.lk> wrote:
>> > Isn't that a bug?
>> > If I declare an NS at the Envelope node then that cannot be removed if
>> > anyone inside uses it. If I'm serializing only the Header element(s)
>> > then
>> > any in scope namespaces must be available and worst case every element
>> > will
>> > re-serialize them. However under no condition is it correct to serialize
>> > a
>> > child element and end up with malformed XML!
>> >
>> > Sanjiva.
>> >
>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
>> > <an...@gmail.com> wrote:
>> >>
>> >> Assuming that the namespace in question is not the SOAP envelope
>> >> namespace, instead of hacking Axiom, wouldn't it be easier to remove
>> >> the namespace declaration from the SOAP envelope (so that it will be
>> >> serialized in the SOAP header block)?
>> >>
>> >> Andreas
>> >>
>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>> >> <ch...@gmail.com> wrote:
>> >> > Hi Andreas,
>> >> >
>> >> > Issue was this causes an Error in a 3rd party web-service engine when
>> >> > processing some soap headers.
>> >> >
>> >> > Scenario is this. Synapse get a soap request which contains some
>> >> > redundant
>> >> > namespace declarations at header level which are internally used
>> >> > inside
>> >> > the
>> >> > headers. So when synapse forward them to the BE service they get
>> >> > omitted as
>> >> > they are defined at SOAP Envelope level.
>> >> >
>> >> > BE services header processor incorrectly assumes that headers are
>> >> > self
>> >> > contained so this causes an error.
>> >> >
>> >> > I was wondering it may make scene to make it configurable as if we
>> >> > think
>> >> > of synapse point of view omitting redundant namespaces may not be a
>> >> > good
>> >> > idea sometimes. Specially integrating with legacies like this. WDYT ?
>> >> > (
>> >> > I do
>> >> > agree that this in pure AXIOM point of view its the correct thing to
>> >> > do
>> >> > as
>> >> > it will reduce the data content that is written to the wire etc.. )
>> >> >
>> >> > Can please you point me to a place where this is done ? So that i can
>> >> > hack
>> >> > the code for the time being for my self and later provide a patch if
>> >> > devs
>> >> > are ok with my above idea.
>> >> >
>> >> > thanks,
>> >> > Charith
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> No, the namespace repairing performed by the serialize and
>> >> >> serializeAndConsume methods is not configurable.
>> >> >>
>> >> >> What is the use case for preserving a redundant namespace
>> >> >> declaration
>> >> >> on a SOAP header?
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>> >> >> <ch...@gmail.com> wrote:
>> >> >> > Hi devs ,
>> >> >> >
>> >> >> > When we serialize a OMElement axiom will omit redundant namesspace
>> >> >> > declarations by default. Is it possible to disable this behavior ?
>> >> >> > In my case i want to keep the redundant namesspace declarations in
>> >> >> > SOAP
>> >> >> > headers.
>> >> >> >
>> >> >> >
>> >> >> > thanks,
>> >> >> > Charith
>> >> >> >
>> >> >> > --
>> >> >> > Charith Dhanushka Wickramarachchi
>> >> >> > http://charithwiki.blogspot.com/
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Charith Dhanushka Wickramarachchi
>> >> > http://charithwiki.blogspot.com/
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Redundant names space removal when Serializing - AXIOM
Posted by Charith Wickramarachchi <ch...@gmail.com>.
On Mon, Nov 21, 2011 at 10:59 PM, Eran Chinthaka Withana <
eran.chinthaka@gmail.com> wrote:
> Hi Charith,
>
> Trying to understand this still.
>
> From the example, seems like the output XML does not contain the namespace
> declaration related to saml prefix. Who removes it from the original
> message and put it inside the output message? Thats the important question
> I think.
>
Hi Eran ,
That is a dummy soap i put to explain the scenario. Please ignore that
missing saml prefix declaration. The issue is Axiom removes this redundant
NS in the <saml:Assertion when serializing.
So i think it'll be a good idea to provide an option to preserve redundant
NS which serializing. In my case as a synapse user I do not expect Axiom to
do optimizations like this.
thanks,
Charith
>
> Andreas, even though there are no specs defining the "right" behavior the
> rule I always went with Axiom was the idea of namespace context. If a node
> gets removed from a tree it should have the namespace context. If it gets
> added to a new tree, then this context should fuse with the new tree. From
> the look of this error it is not happening.
>
> Also, as Andreas mentioned Axiom never produces mal-formed xml (thanks to
> our parsers mainly). But seems like it does. Charith, can you please try to
> dig a little bit deeper?
>
> (Disclaimer: last time I saw Axiom code was when we had black and white
> TVs :) My knowledge on this can be old but I assume concepts have not
> changed)
>
> Thanks,
> Eran Chinthaka Withana
>
>
>
> On Sun, Nov 20, 2011 at 8:31 PM, Charith Wickramarachchi <
> charith.dhanushka@gmail.com> wrote:
>
>> Hi ,
>>
>> Looked more in to the details of whats happening. So here the problem is
>> the element that have this redundant names space is the <saml:Assertion
>> ... element which is a signed one.
>>
>>
>> The incoming message to synapse looks like this.
>>
>> <soapenv:Envelope xmlns:soapenv="
>> http://schemas.xmlsoap.org/soap/envelope/" xmlns:oas="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <soapenv:Header>
>> <oas:Security>
>> <saml:Assertion .... xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> ... </saml:Assertion>
>> </oas:Security>
>> </soapenv:Header>
>> ...........................
>> </soapenv:Envelope>
>>
>>
>> and output is like
>>
>> <soapenv:Envelope xmlns:soapenv="
>> http://schemas.xmlsoap.org/soap/envelope/" xmlns:oas="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <soapenv:Header>
>> <oas:Security>
>> <saml:Assertion ...> ... </saml:Assertion>
>> </oas:Security>
>> </soapenv:Header>
>>
>>
>> So in this case isn't it wrong to do this kind of optimizations ?
>>
>> thanks,
>> Charith
>>
>>
>>
>>
>>
>> On Mon, Nov 21, 2011 at 8:50 AM, Charith Wickramarachchi <
>> charith.dhanushka@gmail.com> wrote:
>>
>>> Hi ,
>>>
>>> This is an issue with the BE service. When the message comes to synapse
>>> from the client. In its SOAP Message it has same name space declared at two
>>> levels.
>>>
>>> At Envelope level and and inside a header. So as a result when message
>>> go through synapse it will omit this redundant names space declaration.
>>> But BE service will fail to process this header due to missing
>>> namesspace. So its due to BEs xml phaser assumes that headers are self
>>> contained and they do not see the namesspace defined at Envelope level.
>>>
>>> thanks,
>>> Charith
>>>
>>>
>>> On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana <
>>> sanjiva@opensource.lk> wrote:
>>>
>>>> "So when synapse forward them to the BE service they get omitted as
>>>> they are defined at SOAP Envelope level."
>>>>
>>>> Maybe Synapse is not serializing the headers properly?
>>>>
>>>> Sanjiva.
>>>>
>>>> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen <
>>>> andreas.veithen@gmail.com> wrote:
>>>>
>>>>> Axiom never produces malformed XML. Who said that??
>>>>>
>>>>> Andreas
>>>>>
>>>>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
>>>>> <sa...@opensource.lk> wrote:
>>>>> > Isn't that a bug?
>>>>> > If I declare an NS at the Envelope node then that cannot be removed
>>>>> if
>>>>> > anyone inside uses it. If I'm serializing only the Header element(s)
>>>>> then
>>>>> > any in scope namespaces must be available and worst case every
>>>>> element will
>>>>> > re-serialize them. However under no condition is it correct to
>>>>> serialize a
>>>>> > child element and end up with malformed XML!
>>>>> >
>>>>> > Sanjiva.
>>>>> >
>>>>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
>>>>> > <an...@gmail.com> wrote:
>>>>> >>
>>>>> >> Assuming that the namespace in question is not the SOAP envelope
>>>>> >> namespace, instead of hacking Axiom, wouldn't it be easier to remove
>>>>> >> the namespace declaration from the SOAP envelope (so that it will be
>>>>> >> serialized in the SOAP header block)?
>>>>> >>
>>>>> >> Andreas
>>>>> >>
>>>>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>>>>> >> <ch...@gmail.com> wrote:
>>>>> >> > Hi Andreas,
>>>>> >> >
>>>>> >> > Issue was this causes an Error in a 3rd party web-service engine
>>>>> when
>>>>> >> > processing some soap headers.
>>>>> >> >
>>>>> >> > Scenario is this. Synapse get a soap request which contains some
>>>>> >> > redundant
>>>>> >> > namespace declarations at header level which are internally used
>>>>> inside
>>>>> >> > the
>>>>> >> > headers. So when synapse forward them to the BE service they get
>>>>> >> > omitted as
>>>>> >> > they are defined at SOAP Envelope level.
>>>>> >> >
>>>>> >> > BE services header processor incorrectly assumes that headers are
>>>>> self
>>>>> >> > contained so this causes an error.
>>>>> >> >
>>>>> >> > I was wondering it may make scene to make it configurable as if
>>>>> we
>>>>> >> > think
>>>>> >> > of synapse point of view omitting redundant namespaces may not
>>>>> be a
>>>>> >> > good
>>>>> >> > idea sometimes. Specially integrating with legacies like this.
>>>>> WDYT ? (
>>>>> >> > I do
>>>>> >> > agree that this in pure AXIOM point of view its the correct thing
>>>>> to do
>>>>> >> > as
>>>>> >> > it will reduce the data content that is written to the wire etc..
>>>>> )
>>>>> >> >
>>>>> >> > Can please you point me to a place where this is done ? So that i
>>>>> can
>>>>> >> > hack
>>>>> >> > the code for the time being for my self and later provide a patch
>>>>> if
>>>>> >> > devs
>>>>> >> > are ok with my above idea.
>>>>> >> >
>>>>> >> > thanks,
>>>>> >> > Charith
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>>>>> >> > <an...@gmail.com>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> No, the namespace repairing performed by the serialize and
>>>>> >> >> serializeAndConsume methods is not configurable.
>>>>> >> >>
>>>>> >> >> What is the use case for preserving a redundant namespace
>>>>> declaration
>>>>> >> >> on a SOAP header?
>>>>> >> >>
>>>>> >> >> Andreas
>>>>> >> >>
>>>>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>>>>> >> >> <ch...@gmail.com> wrote:
>>>>> >> >> > Hi devs ,
>>>>> >> >> >
>>>>> >> >> > When we serialize a OMElement axiom will omit redundant
>>>>> namesspace
>>>>> >> >> > declarations by default. Is it possible to disable this
>>>>> behavior ?
>>>>> >> >> > In my case i want to keep the redundant namesspace
>>>>> declarations in
>>>>> >> >> > SOAP
>>>>> >> >> > headers.
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > thanks,
>>>>> >> >> > Charith
>>>>> >> >> >
>>>>> >> >> > --
>>>>> >> >> > Charith Dhanushka Wickramarachchi
>>>>> >> >> > http://charithwiki.blogspot.com/
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >>
>>>>> ---------------------------------------------------------------------
>>>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>>>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > Charith Dhanushka Wickramarachchi
>>>>> >> > http://charithwiki.blogspot.com/
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> ---------------------------------------------------------------------
>>>>> >> 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/
>>>>
>>>>
>>>
>>>
>>> --
>>> Charith Dhanushka Wickramarachchi
>>> http://charithwiki.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Prabath Siriwardena <pr...@wso2.com>.
On Thu, Nov 24, 2011 at 12:07 PM, Prabath Siriwardena <pr...@wso2.com>wrote:
> Please see section 5.4.3 of SAML Core spec
>
> "SAML implementations SHOULD use Exclusive Canonicalization [Excl-C14N],
> with or without comments,both in the <ds:CanonicalizationMethod> element of
> <ds:SignedInfo>, and as a
> <ds:Transform> algorithm. Use of Exclusive Canonicalization ensures that
> signatures created over SAML messages embedded in an XML context can be
> verified independent of that context"
>
> That justifies why we sign only the Assertion element - and why it should
> be self contained...
>
> > 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.
>
> Yes..
>
> > A likely explanation that it detaches the SAML assertion but fails to
> preserve the required namespace context in that operation.
>
> No - in fact it becomes an invalid signature - when the issuer signs the
> message it's done for a self contained SAML assertion - with the namespace
> - but after that namespace being removed, the BE service verifies the
> signature against an altered message.. Hence the signature validation
> fails..
>
Yes - your explanation is right here - sorry, I misread it first..
Thanks & regards,
-Prabath
>
> Thanks & regards,
> -Prabath
>
> [1]:
> http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
>
> On Thu, Nov 24, 2011 at 4:10 AM, Andreas Veithen <
> andreas.veithen@gmail.com> wrote:
>
>> 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 <pr...@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 <pr...@wso2.com>
>> >> wrote:
>> >> >
>> >> > Hi Andreas;
>> >> > On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen
>> >> > <an...@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
>> >> >> > <sa...@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
>> >> >> >> <an...@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
>> >> >> >>> <sa...@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
>> >> >> >>> > <an...@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
>> >> >> >>> >> <sa...@opensource.lk> wrote:
>> >> >> >>> >> > http://www.w3.org/TR/xml-c14n
>> >> >> >>> >> >
>> >> >> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>> >> >> >>> >> > <sa...@opensource.lk>
>> >> >> >>> >> > wrote:
>> >> >> >>> >> >>
>> >> >> >>> >> >> Please look at the C14N spec.
>> >> >> >>> >> >>
>> >> >> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>> >> >> >>> >> >> <an...@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
>> >> >> >>> >> >>> <sa...@opensource.lk> wrote:
>> >> >> >>> >> >>> > Thanks for the clear writeup Andreas.
>> >> >> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>> >> >> >>> >> >>> > <an...@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
>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
--
Thanks & Regards,
Prabath
http://blog.facilelogin.com
http://RampartFAQ.com
Re: Redundant names space removal when Serializing - AXIOM
Posted by Prabath Siriwardena <pr...@wso2.com>.
Please see section 5.4.3 of SAML Core spec
"SAML implementations SHOULD use Exclusive Canonicalization [Excl-C14N],
with or without comments,both in the <ds:CanonicalizationMethod> element of
<ds:SignedInfo>, and as a
<ds:Transform> algorithm. Use of Exclusive Canonicalization ensures that
signatures created over SAML messages embedded in an XML context can be
verified independent of that context"
That justifies why we sign only the Assertion element - and why it should
be self contained...
> 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.
Yes..
> A likely explanation that it detaches the SAML assertion but fails to
preserve the required namespace context in that operation.
No - in fact it becomes an invalid signature - when the issuer signs the
message it's done for a self contained SAML assertion - with the namespace
- but after that namespace being removed, the BE service verifies the
signature against an altered message.. Hence the signature validation
fails..
Thanks & regards,
-Prabath
[1]:
http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
On Thu, Nov 24, 2011 at 4:10 AM, Andreas Veithen
<an...@gmail.com>wrote:
> 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 <pr...@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 <pr...@wso2.com>
> >> wrote:
> >> >
> >> > Hi Andreas;
> >> > On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen
> >> > <an...@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
> >> >> > <sa...@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
> >> >> >> <an...@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
> >> >> >>> <sa...@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
> >> >> >>> > <an...@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
> >> >> >>> >> <sa...@opensource.lk> wrote:
> >> >> >>> >> > http://www.w3.org/TR/xml-c14n
> >> >> >>> >> >
> >> >> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
> >> >> >>> >> > <sa...@opensource.lk>
> >> >> >>> >> > wrote:
> >> >> >>> >> >>
> >> >> >>> >> >> Please look at the C14N spec.
> >> >> >>> >> >>
> >> >> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
> >> >> >>> >> >> <an...@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
> >> >> >>> >> >>> <sa...@opensource.lk> wrote:
> >> >> >>> >> >>> > Thanks for the clear writeup Andreas.
> >> >> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> >> >> >>> >> >>> > <an...@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
>
>
--
Thanks & Regards,
Prabath
http://blog.facilelogin.com
http://RampartFAQ.com
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
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 <pr...@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 <an...@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 <pr...@wso2.com>
>> wrote:
>> >
>> > Hi Andreas;
>> > On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen
>> > <an...@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 <pr...@wso2.com>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana
>> >> > <sa...@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
>> >> >> <an...@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
>> >> >>> <sa...@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
>> >> >>> > <an...@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
>> >> >>> >> <sa...@opensource.lk> wrote:
>> >> >>> >> > http://www.w3.org/TR/xml-c14n
>> >> >>> >> >
>> >> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>> >> >>> >> > <sa...@opensource.lk>
>> >> >>> >> > wrote:
>> >> >>> >> >>
>> >> >>> >> >> Please look at the C14N spec.
>> >> >>> >> >>
>> >> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>> >> >>> >> >> <an...@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
>> >> >>> >> >>> <sa...@opensource.lk> wrote:
>> >> >>> >> >>> > Thanks for the clear writeup Andreas.
>> >> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>> >> >>> >> >>> > <an...@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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Prabath Siriwardena <pr...@wso2.com>.
The section "5 SAML and XML Signature Syntax and Processing" of SAML core
specification may be helpful..
Thanks & regards,
-Prabath
On Wed, Nov 23, 2011 at 7:36 PM, Prabath Siriwardena <pr...@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 <pr...@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 <pr...@wso2.com>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana
>> >> > <sa...@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
>> >> >> <an...@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
>> >> >>> <sa...@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
>> >> >>> > <an...@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
>> >> >>> >> <sa...@opensource.lk> wrote:
>> >> >>> >> > http://www.w3.org/TR/xml-c14n
>> >> >>> >> >
>> >> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>> >> >>> >> > <sa...@opensource.lk>
>> >> >>> >> > wrote:
>> >> >>> >> >>
>> >> >>> >> >> Please look at the C14N spec.
>> >> >>> >> >>
>> >> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>> >> >>> >> >> <an...@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
>> >> >>> >> >>> <sa...@opensource.lk> wrote:
>> >> >>> >> >>> > Thanks for the clear writeup Andreas.
>> >> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>> >> >>> >> >>> > <an...@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
>
--
Thanks & Regards,
Prabath
http://blog.facilelogin.com
http://RampartFAQ.com
Re: Redundant names space removal when Serializing - AXIOM
Posted by Prabath Siriwardena <pr...@wso2.com>.
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
<an...@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 <pr...@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 <pr...@wso2.com>
> >> wrote:
> >> >
> >> >
> >> > On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana
> >> > <sa...@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
> >> >> <an...@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
> >> >>> <sa...@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
> >> >>> > <an...@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
> >> >>> >> <sa...@opensource.lk> wrote:
> >> >>> >> > http://www.w3.org/TR/xml-c14n
> >> >>> >> >
> >> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
> >> >>> >> > <sa...@opensource.lk>
> >> >>> >> > wrote:
> >> >>> >> >>
> >> >>> >> >> Please look at the C14N spec.
> >> >>> >> >>
> >> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
> >> >>> >> >> <an...@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
> >> >>> >> >>> <sa...@opensource.lk> wrote:
> >> >>> >> >>> > Thanks for the clear writeup Andreas.
> >> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> >> >>> >> >>> > <an...@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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
"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 <pr...@wso2.com> wrote:
>
> Hi Andreas;
> On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen <an...@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 <pr...@wso2.com>
>> wrote:
>> >
>> >
>> > On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana
>> > <sa...@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
>> >> <an...@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
>> >>> <sa...@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
>> >>> > <an...@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
>> >>> >> <sa...@opensource.lk> wrote:
>> >>> >> > http://www.w3.org/TR/xml-c14n
>> >>> >> >
>> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>> >>> >> > <sa...@opensource.lk>
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> Please look at the C14N spec.
>> >>> >> >>
>> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>> >>> >> >> <an...@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
>> >>> >> >>> <sa...@opensource.lk> wrote:
>> >>> >> >>> > Thanks for the clear writeup Andreas.
>> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>> >>> >> >>> > <an...@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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Prabath Siriwardena <pr...@wso2.com>.
Hi Andreas;
On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen
<an...@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 <pr...@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
> >> <an...@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
> >>> <sa...@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
> >>> > <an...@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
> >>> >> <sa...@opensource.lk> wrote:
> >>> >> > http://www.w3.org/TR/xml-c14n
> >>> >> >
> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
> >>> >> > <sa...@opensource.lk>
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> Please look at the C14N spec.
> >>> >> >>
> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
> >>> >> >> <an...@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
> >>> >> >>> <sa...@opensource.lk> wrote:
> >>> >> >>> > Thanks for the clear writeup Andreas.
> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> >>> >> >>> > <an...@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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
My apologies for making "questionable statements about specs".
On Thu, Nov 24, 2011 at 4:12 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Dude, if you had not started to make questionable statements about the
> specs, we could have come to the conclusions much earlier...
>
> Of course, adding an option to Axiom to disable the removal of
> redundant namespace declarations is a perfectly reasonable
> requirement. I would even go a step further and also allow to disable
> namespace repairing altogether. In fact, if one parses an XML document
> and later serializes it again without doing any structural
> modifications, then it will automatically be well formed with respect
> to namespaces. In that case, namespace repairing is just unnecessary
> overhead. IMHO this is an even more relevant requirement because the
> redundant namespace thing is only important when interacting with
> broken services.
>
> However, I wouldn't speak about "serialize back to the EXACT xml"
> (certainly not in upper case letters...) because the serialized XML
> will almost never be exactly the same.
>
> Andreas
> On Wed, Nov 23, 2011 at 16:39, Sanjiva Weerawarana
> <sa...@opensource.lk> wrote:
> > Andreas, independent of the discussion on whether what Axiom's
> serializer is
> > doing is affecting C14N or not, it is a perfectly reasonable requirement
> to
> > be able to serialize back to the EXACT xml from which the Axiom model was
> > built.
> > No one is asking for this to change default behavior. This is about
> making
> > Axiom more useful for a wider group of people and hence a perfectly
> > reasonable thing to do!
> >
> > Sanjiva.
> >
> > 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?
> >>
> >> Andreas
> >>
> >> On Wed, Nov 23, 2011 at 08:49, Prabath Siriwardena <pr...@wso2.com>
> >> wrote:
> >> >
> >> >
> >> > On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana
> >> > <sa...@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
> >> >> <an...@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
> >> >>> <sa...@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
> >> >>> > <an...@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
> >> >>> >> <sa...@opensource.lk> wrote:
> >> >>> >> > http://www.w3.org/TR/xml-c14n
> >> >>> >> >
> >> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
> >> >>> >> > <sa...@opensource.lk>
> >> >>> >> > wrote:
> >> >>> >> >>
> >> >>> >> >> Please look at the C14N spec.
> >> >>> >> >>
> >> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
> >> >>> >> >> <an...@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
> >> >>> >> >>> <sa...@opensource.lk> wrote:
> >> >>> >> >>> > Thanks for the clear writeup Andreas.
> >> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> >> >>> >> >>> > <an...@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
> >>
> >
> >
> >
> > --
> > 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/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
Dude, if you had not started to make questionable statements about the
specs, we could have come to the conclusions much earlier...
Of course, adding an option to Axiom to disable the removal of
redundant namespace declarations is a perfectly reasonable
requirement. I would even go a step further and also allow to disable
namespace repairing altogether. In fact, if one parses an XML document
and later serializes it again without doing any structural
modifications, then it will automatically be well formed with respect
to namespaces. In that case, namespace repairing is just unnecessary
overhead. IMHO this is an even more relevant requirement because the
redundant namespace thing is only important when interacting with
broken services.
However, I wouldn't speak about "serialize back to the EXACT xml"
(certainly not in upper case letters...) because the serialized XML
will almost never be exactly the same.
Andreas
On Wed, Nov 23, 2011 at 16:39, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> Andreas, independent of the discussion on whether what Axiom's serializer is
> doing is affecting C14N or not, it is a perfectly reasonable requirement to
> be able to serialize back to the EXACT xml from which the Axiom model was
> built.
> No one is asking for this to change default behavior. This is about making
> Axiom more useful for a wider group of people and hence a perfectly
> reasonable thing to do!
>
> Sanjiva.
>
> On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen <an...@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?
>>
>> Andreas
>>
>> On Wed, Nov 23, 2011 at 08:49, Prabath Siriwardena <pr...@wso2.com>
>> wrote:
>> >
>> >
>> > On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana
>> > <sa...@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
>> >> <an...@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
>> >>> <sa...@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
>> >>> > <an...@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
>> >>> >> <sa...@opensource.lk> wrote:
>> >>> >> > http://www.w3.org/TR/xml-c14n
>> >>> >> >
>> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>> >>> >> > <sa...@opensource.lk>
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> Please look at the C14N spec.
>> >>> >> >>
>> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>> >>> >> >> <an...@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
>> >>> >> >>> <sa...@opensource.lk> wrote:
>> >>> >> >>> > Thanks for the clear writeup Andreas.
>> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>> >>> >> >>> > <an...@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
>>
>
>
>
> --
> 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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Andreas, independent of the discussion on whether what Axiom's serializer
is doing is affecting C14N or not, it is a perfectly reasonable requirement
to be able to serialize back to the EXACT xml from which the Axiom model
was built.
No one is asking for this to change default behavior. This is about making
Axiom more useful for a wider group of people and hence a perfectly
reasonable thing to do!
Sanjiva.
On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen
<an...@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?
>
> Andreas
>
> On Wed, Nov 23, 2011 at 08:49, Prabath Siriwardena <pr...@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
> >> <an...@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
> >>> <sa...@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
> >>> > <an...@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
> >>> >> <sa...@opensource.lk> wrote:
> >>> >> > http://www.w3.org/TR/xml-c14n
> >>> >> >
> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
> >>> >> > <sa...@opensource.lk>
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> Please look at the C14N spec.
> >>> >> >>
> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
> >>> >> >> <an...@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
> >>> >> >>> <sa...@opensource.lk> wrote:
> >>> >> >>> > Thanks for the clear writeup Andreas.
> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> >>> >> >>> > <an...@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
>
>
--
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/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
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?
Andreas
On Wed, Nov 23, 2011 at 08:49, Prabath Siriwardena <pr...@wso2.com> wrote:
>
>
> On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana <sa...@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
>> <an...@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
>>> <sa...@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
>>> > <an...@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
>>> >> <sa...@opensource.lk> wrote:
>>> >> > http://www.w3.org/TR/xml-c14n
>>> >> >
>>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>>> >> > <sa...@opensource.lk>
>>> >> > wrote:
>>> >> >>
>>> >> >> Please look at the C14N spec.
>>> >> >>
>>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>>> >> >> <an...@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
>>> >> >>> <sa...@opensource.lk> wrote:
>>> >> >>> > Thanks for the clear writeup Andreas.
>>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>>> >> >>> > <an...@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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Prabath Siriwardena <pr...@wso2.com>.
On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana
<sa...@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
>> <sa...@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
>> >> <sa...@opensource.lk> wrote:
>> >> > http://www.w3.org/TR/xml-c14n
>> >> >
>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>> >> > <sa...@opensource.lk>
>> >> > wrote:
>> >> >>
>> >> >> Please look at the C14N spec.
>> >> >>
>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>> >> >> <an...@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
>> >> >>> <sa...@opensource.lk> wrote:
>> >> >>> > Thanks for the clear writeup Andreas.
>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>> >> >>> > <an...@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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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.
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
> <sa...@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
> >> <sa...@opensource.lk> wrote:
> >> > http://www.w3.org/TR/xml-c14n
> >> >
> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
> >> > <sa...@opensource.lk>
> >> > wrote:
> >> >>
> >> >> Please look at the C14N spec.
> >> >>
> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
> >> >> <an...@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
> >> >>> <sa...@opensource.lk> wrote:
> >> >>> > Thanks for the clear writeup Andreas.
> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> >> >>> > <an...@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/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
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
<sa...@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 <an...@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
>> <sa...@opensource.lk> wrote:
>> > http://www.w3.org/TR/xml-c14n
>> >
>> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>> > <sa...@opensource.lk>
>> > wrote:
>> >>
>> >> Please look at the C14N spec.
>> >>
>> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>> >> <an...@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
>> >>> <sa...@opensource.lk> wrote:
>> >>> > Thanks for the clear writeup Andreas.
>> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>> >>> > <an...@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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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
<an...@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
> <sa...@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
> >> <an...@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
> >>> <sa...@opensource.lk> wrote:
> >>> > Thanks for the clear writeup Andreas.
> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> >>> > <an...@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/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Charith Wickramarachchi <ch...@gmail.com>.
On Wed, Nov 23, 2011 at 12:41 PM, Andreas Veithen <andreas.veithen@gmail.com
> wrote:
> The question about how to remove a namespace declaration is discussed
> in AXIOM-75.
>
Thanks Andreas,
--Charith
>
> Andreas
>
> On Wed, Nov 23, 2011 at 01:20, Charith Wickramarachchi
> <ch...@gmail.com> wrote:
> >
> >
> > On Tue, Nov 22, 2011 at 6:48 PM, Ruwan Linton <ru...@gmail.com>
> > wrote:
> >>
> >> Hi Charith,
> >>
> >> Have you tried changing the namespace prefix within Synapse. I am not
> too
> >> sure whether AXIOM normalizes that as well, but if it doesn't that might
> >> solve the problem. I know xsi is a special case, but I am assuming xsi
> is
> >> not hard coded in the SAML processor BE that you are referring to.
> >>
> >
> >
> > Hi Ruwan ,
> >
> > I was previously trying to remove the namespace declaration with in the
> > synapse from the SOAP envelope level as Andreas suggested. As in this
> case
> > client and BE service are legacies to me. But I couldn't find any Axiom
> api
> > to do that. In my case i can't touch this assertion element as it's a
> signed
> > one.
> >
> > thanks,
> > Charith
> >
> >>
> >> Thanks,
> >> Ruwan
> >>
> >> On Tue, Nov 22, 2011 at 6:36 PM, Andreas Veithen
> >> <an...@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
> >>> <sa...@opensource.lk> wrote:
> >>> > http://www.w3.org/TR/xml-c14n
> >>> >
> >>> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
> >>> > <sa...@opensource.lk>
> >>> > wrote:
> >>> >>
> >>> >> Please look at the C14N spec.
> >>> >>
> >>> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
> >>> >> <an...@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
> >>> >>> <sa...@opensource.lk> wrote:
> >>> >>> > Thanks for the clear writeup Andreas.
> >>> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> >>> >>> > <an...@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
> >>>
> >>
> >>
> >>
> >> --
> >> Ruwan Linton
> >> Member, Apache Software Foundation; http://www.apache.org
> >> Director of Engineering; http://adroitlogic.org
> >>
> >> phone: +94 11 282 7532
> >> email: ruwan@adroitlogic.com; cell: +94 77 341 3097
> >> blog: http://blog.ruwan.org
> >> linkedin: http://www.linkedin.com/in/ruwanlinton
> >> google: http://www.google.com/profiles/ruwan.linton
> >> tweet: http://twitter.com/ruwanlinton
> >
> >
> >
> > --
> > Charith Dhanushka Wickramarachchi
> > http://charithwiki.blogspot.com/
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
The question about how to remove a namespace declaration is discussed
in AXIOM-75.
Andreas
On Wed, Nov 23, 2011 at 01:20, Charith Wickramarachchi
<ch...@gmail.com> wrote:
>
>
> On Tue, Nov 22, 2011 at 6:48 PM, Ruwan Linton <ru...@gmail.com>
> wrote:
>>
>> Hi Charith,
>>
>> Have you tried changing the namespace prefix within Synapse. I am not too
>> sure whether AXIOM normalizes that as well, but if it doesn't that might
>> solve the problem. I know xsi is a special case, but I am assuming xsi is
>> not hard coded in the SAML processor BE that you are referring to.
>>
>
>
> Hi Ruwan ,
>
> I was previously trying to remove the namespace declaration with in the
> synapse from the SOAP envelope level as Andreas suggested. As in this case
> client and BE service are legacies to me. But I couldn't find any Axiom api
> to do that. In my case i can't touch this assertion element as it's a signed
> one.
>
> thanks,
> Charith
>
>>
>> Thanks,
>> Ruwan
>>
>> On Tue, Nov 22, 2011 at 6:36 PM, Andreas Veithen
>> <an...@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
>>> <sa...@opensource.lk> wrote:
>>> > http://www.w3.org/TR/xml-c14n
>>> >
>>> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
>>> > <sa...@opensource.lk>
>>> > wrote:
>>> >>
>>> >> Please look at the C14N spec.
>>> >>
>>> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>>> >> <an...@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
>>> >>> <sa...@opensource.lk> wrote:
>>> >>> > Thanks for the clear writeup Andreas.
>>> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>>> >>> > <an...@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
>>>
>>
>>
>>
>> --
>> Ruwan Linton
>> Member, Apache Software Foundation; http://www.apache.org
>> Director of Engineering; http://adroitlogic.org
>>
>> phone: +94 11 282 7532
>> email: ruwan@adroitlogic.com; cell: +94 77 341 3097
>> blog: http://blog.ruwan.org
>> linkedin: http://www.linkedin.com/in/ruwanlinton
>> google: http://www.google.com/profiles/ruwan.linton
>> tweet: http://twitter.com/ruwanlinton
>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Redundant names space removal when Serializing - AXIOM
Posted by Charith Wickramarachchi <ch...@gmail.com>.
On Tue, Nov 22, 2011 at 6:48 PM, Ruwan Linton <ru...@gmail.com>wrote:
> Hi Charith,
>
> Have you tried changing the namespace prefix within Synapse. I am not too
> sure whether AXIOM normalizes that as well, but if it doesn't that might
> solve the problem. I know xsi is a special case, but I am assuming xsi is
> not hard coded in the SAML processor BE that you are referring to.
>
>
Hi Ruwan ,
I was previously trying to remove the namespace declaration with in the
synapse from the SOAP envelope level as Andreas suggested. As in this case
client and BE service are legacies to me. But I couldn't find any Axiom api
to do that. In my case i can't touch this assertion element as it's a
signed one.
thanks,
Charith
> Thanks,
> Ruwan
>
>
> 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
>> <sa...@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
>> >> <an...@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
>> >>> <sa...@opensource.lk> wrote:
>> >>> > Thanks for the clear writeup Andreas.
>> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>> >>> > <an...@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
>>
>>
>
>
> --
> Ruwan Linton
> Member, Apache Software Foundation; http://www.apache.org
> Director of Engineering; http://adroitlogic.org
> <http://wso2.org>
>
> phone: +94 11 282 7532
> email: ruwan@adroitlogic.com; cell: +94 77 341 3097
> blog: http://blog.ruwan.org
> linkedin: http://www.linkedin.com/in/ruwanlinton
> google: http://www.google.com/profiles/ruwan.linton
> tweet: http://twitter.com/ruwanlinton
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Charith,
Have you tried changing the namespace prefix within Synapse. I am not too
sure whether AXIOM normalizes that as well, but if it doesn't that might
solve the problem. I know xsi is a special case, but I am assuming xsi is
not hard coded in the SAML processor BE that you are referring to.
Thanks,
Ruwan
On Tue, Nov 22, 2011 at 6:36 PM, Andreas Veithen
<an...@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
> <sa...@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
> >> <an...@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
> >>> <sa...@opensource.lk> wrote:
> >>> > Thanks for the clear writeup Andreas.
> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> >>> > <an...@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
>
>
--
Ruwan Linton
Member, Apache Software Foundation; http://www.apache.org
Director of Engineering; http://adroitlogic.org
<http://wso2.org>
phone: +94 11 282 7532
email: ruwan@adroitlogic.com; cell: +94 77 341 3097
blog: http://blog.ruwan.org
linkedin: http://www.linkedin.com/in/ruwanlinton
google: http://www.google.com/profiles/ruwan.linton
tweet: http://twitter.com/ruwanlinton
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
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
<sa...@opensource.lk> wrote:
> http://www.w3.org/TR/xml-c14n
>
> On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana <sa...@opensource.lk>
> wrote:
>>
>> Please look at the C14N spec.
>>
>> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
>> <an...@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
>>> <sa...@opensource.lk> wrote:
>>> > Thanks for the clear writeup Andreas.
>>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>>> > <an...@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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
http://www.w3.org/TR/xml-c14n
On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana
<sa...@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
>> <sa...@opensource.lk> wrote:
>> > Thanks for the clear writeup Andreas.
>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
>> > <an...@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/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Please look at the C14N spec.
On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen
<an...@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
> <sa...@opensource.lk> wrote:
> > Thanks for the clear writeup Andreas.
> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> > <an...@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/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
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
<sa...@opensource.lk> wrote:
> Thanks for the clear writeup Andreas.
> On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen
> <an...@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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
Eran & Aleksander,
These are interesting discussions, but they have nothing to do with
the problem. I think that you didn't read the thread carefully from
the beginning. There is no node being detached, there is no
serialization of a subtree, there is no namespace context being lost
and there is no generation of malformed XML anywhere.
The scenario is this: Axiom is used to parse a document that contains
a redundant namespace declaration, i.e. a namespace declaration for
which another namespace declaration with the same prefix and URI is
already in scope on the parent element. In Charith's sample this is
the xmlns:xsi declaration that is present on the SOAP envelope and on
the SAML assertion.
The current behavior of Axiom is as follows (and it has always been
since I started to work on Axiom, but that was when colour TV already
existed...):
* The object model will contain an object for each namespace
declarations appearing in the original document, even for redundant
ones.
* The serializer performs namespace repairing and (in addition to
generating extra namespace declarations where necessary) skips the
serialization of redundant namespace declarations (as defined above).
>From the perspective of the core XML specs, this is a perfectly valid
thing to do because the resulting XML document is well formed and the
namespace context of each and every element is strictly preserved.
As Charith pointed out, the SAML assertion is signed. As you know,
before an element is signed, it is first canonicalized. This is where
the real question is: is any of the C14N schemes sensitive to the
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).
Andreas
On Mon, Nov 21, 2011 at 18:29, Eran Chinthaka Withana
<er...@gmail.com> wrote:
> Hi Charith,
> Trying to understand this still.
> From the example, seems like the output XML does not contain the namespace
> declaration related to saml prefix. Who removes it from the original message
> and put it inside the output message? Thats the important question I think.
> Andreas, even though there are no specs defining the "right" behavior the
> rule I always went with Axiom was the idea of namespace context. If a node
> gets removed from a tree it should have the namespace context. If it gets
> added to a new tree, then this context should fuse with the new tree. From
> the look of this error it is not happening.
> Also, as Andreas mentioned Axiom never produces mal-formed xml (thanks to
> our parsers mainly). But seems like it does. Charith, can you please try to
> dig a little bit deeper?
> (Disclaimer: last time I saw Axiom code was when we had black and white TVs
> :) My knowledge on this can be old but I assume concepts have not changed)
> Thanks,
> Eran Chinthaka Withana
>
>
> On Sun, Nov 20, 2011 at 8:31 PM, Charith Wickramarachchi
> <ch...@gmail.com> wrote:
>>
>> Hi ,
>>
>> Looked more in to the details of whats happening. So here the problem is
>> the element that have this redundant names space is the <saml:Assertion ...
>> element which is a signed one.
>>
>>
>> The incoming message to synapse looks like this.
>>
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <soapenv:Header>
>> <oas:Security>
>> <saml:Assertion ....
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ...
>> </saml:Assertion>
>> </oas:Security>
>> </soapenv:Header>
>> ...........................
>> </soapenv:Envelope>
>>
>>
>> and output is like
>>
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <soapenv:Header>
>> <oas:Security>
>> <saml:Assertion ...> ... </saml:Assertion>
>> </oas:Security>
>> </soapenv:Header>
>>
>>
>> So in this case isn't it wrong to do this kind of optimizations ?
>>
>> thanks,
>> Charith
>>
>>
>>
>>
>>
>> On Mon, Nov 21, 2011 at 8:50 AM, Charith Wickramarachchi
>> <ch...@gmail.com> wrote:
>>>
>>> Hi ,
>>>
>>> This is an issue with the BE service. When the message comes to synapse
>>> from the client. In its SOAP Message it has same name space declared at two
>>> levels.
>>>
>>> At Envelope level and and inside a header. So as a result when message go
>>> through synapse it will omit this redundant names space declaration.
>>> But BE service will fail to process this header due to missing
>>> namesspace. So its due to BEs xml phaser assumes that headers are self
>>> contained and they do not see the namesspace defined at Envelope level.
>>>
>>> thanks,
>>> Charith
>>>
>>> On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana
>>> <sa...@opensource.lk> wrote:
>>>>
>>>> "So when synapse forward them to the BE service they get omitted as
>>>> they are defined at SOAP Envelope level."
>>>> Maybe Synapse is not serializing the headers properly?
>>>> Sanjiva.
>>>>
>>>> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen
>>>> <an...@gmail.com> wrote:
>>>>>
>>>>> Axiom never produces malformed XML. Who said that??
>>>>>
>>>>> Andreas
>>>>>
>>>>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
>>>>> <sa...@opensource.lk> wrote:
>>>>> > Isn't that a bug?
>>>>> > If I declare an NS at the Envelope node then that cannot be removed
>>>>> > if
>>>>> > anyone inside uses it. If I'm serializing only the Header element(s)
>>>>> > then
>>>>> > any in scope namespaces must be available and worst case every
>>>>> > element will
>>>>> > re-serialize them. However under no condition is it correct to
>>>>> > serialize a
>>>>> > child element and end up with malformed XML!
>>>>> >
>>>>> > Sanjiva.
>>>>> >
>>>>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
>>>>> > <an...@gmail.com> wrote:
>>>>> >>
>>>>> >> Assuming that the namespace in question is not the SOAP envelope
>>>>> >> namespace, instead of hacking Axiom, wouldn't it be easier to remove
>>>>> >> the namespace declaration from the SOAP envelope (so that it will be
>>>>> >> serialized in the SOAP header block)?
>>>>> >>
>>>>> >> Andreas
>>>>> >>
>>>>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>>>>> >> <ch...@gmail.com> wrote:
>>>>> >> > Hi Andreas,
>>>>> >> >
>>>>> >> > Issue was this causes an Error in a 3rd party web-service engine
>>>>> >> > when
>>>>> >> > processing some soap headers.
>>>>> >> >
>>>>> >> > Scenario is this. Synapse get a soap request which contains some
>>>>> >> > redundant
>>>>> >> > namespace declarations at header level which are internally used
>>>>> >> > inside
>>>>> >> > the
>>>>> >> > headers. So when synapse forward them to the BE service they get
>>>>> >> > omitted as
>>>>> >> > they are defined at SOAP Envelope level.
>>>>> >> >
>>>>> >> > BE services header processor incorrectly assumes that headers are
>>>>> >> > self
>>>>> >> > contained so this causes an error.
>>>>> >> >
>>>>> >> > I was wondering it may make scene to make it configurable as if
>>>>> >> > we
>>>>> >> > think
>>>>> >> > of synapse point of view omitting redundant namespaces may not be
>>>>> >> > a
>>>>> >> > good
>>>>> >> > idea sometimes. Specially integrating with legacies like this.
>>>>> >> > WDYT ? (
>>>>> >> > I do
>>>>> >> > agree that this in pure AXIOM point of view its the correct thing
>>>>> >> > to do
>>>>> >> > as
>>>>> >> > it will reduce the data content that is written to the wire etc..
>>>>> >> > )
>>>>> >> >
>>>>> >> > Can please you point me to a place where this is done ? So that i
>>>>> >> > can
>>>>> >> > hack
>>>>> >> > the code for the time being for my self and later provide a patch
>>>>> >> > if
>>>>> >> > devs
>>>>> >> > are ok with my above idea.
>>>>> >> >
>>>>> >> > thanks,
>>>>> >> > Charith
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>>>>> >> > <an...@gmail.com>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> No, the namespace repairing performed by the serialize and
>>>>> >> >> serializeAndConsume methods is not configurable.
>>>>> >> >>
>>>>> >> >> What is the use case for preserving a redundant namespace
>>>>> >> >> declaration
>>>>> >> >> on a SOAP header?
>>>>> >> >>
>>>>> >> >> Andreas
>>>>> >> >>
>>>>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>>>>> >> >> <ch...@gmail.com> wrote:
>>>>> >> >> > Hi devs ,
>>>>> >> >> >
>>>>> >> >> > When we serialize a OMElement axiom will omit redundant
>>>>> >> >> > namesspace
>>>>> >> >> > declarations by default. Is it possible to disable this
>>>>> >> >> > behavior ?
>>>>> >> >> > In my case i want to keep the redundant namesspace declarations
>>>>> >> >> > in
>>>>> >> >> > SOAP
>>>>> >> >> > headers.
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > thanks,
>>>>> >> >> > Charith
>>>>> >> >> >
>>>>> >> >> > --
>>>>> >> >> > Charith Dhanushka Wickramarachchi
>>>>> >> >> > http://charithwiki.blogspot.com/
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> ---------------------------------------------------------------------
>>>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>>>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > Charith Dhanushka Wickramarachchi
>>>>> >> > http://charithwiki.blogspot.com/
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >> 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/
>>>
>>>
>>>
>>> --
>>> Charith Dhanushka Wickramarachchi
>>> http://charithwiki.blogspot.com/
>>>
>>
>>
>>
>> --
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Redundant names space removal when Serializing - AXIOM
Posted by Eran Chinthaka Withana <er...@gmail.com>.
Hi Charith,
Trying to understand this still.
>From the example, seems like the output XML does not contain the namespace
declaration related to saml prefix. Who removes it from the original
message and put it inside the output message? Thats the important question
I think.
Andreas, even though there are no specs defining the "right" behavior the
rule I always went with Axiom was the idea of namespace context. If a node
gets removed from a tree it should have the namespace context. If it gets
added to a new tree, then this context should fuse with the new tree. From
the look of this error it is not happening.
Also, as Andreas mentioned Axiom never produces mal-formed xml (thanks to
our parsers mainly). But seems like it does. Charith, can you please try to
dig a little bit deeper?
(Disclaimer: last time I saw Axiom code was when we had black and white TVs
:) My knowledge on this can be old but I assume concepts have not changed)
Thanks,
Eran Chinthaka Withana
On Sun, Nov 20, 2011 at 8:31 PM, Charith Wickramarachchi <
charith.dhanushka@gmail.com> wrote:
> Hi ,
>
> Looked more in to the details of whats happening. So here the problem is
> the element that have this redundant names space is the <saml:Assertion
> ... element which is a signed one.
>
>
> The incoming message to synapse looks like this.
>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:oas="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Header>
> <oas:Security>
> <saml:Assertion .... xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> ... </saml:Assertion>
> </oas:Security>
> </soapenv:Header>
> ...........................
> </soapenv:Envelope>
>
>
> and output is like
>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:oas="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Header>
> <oas:Security>
> <saml:Assertion ...> ... </saml:Assertion>
> </oas:Security>
> </soapenv:Header>
>
>
> So in this case isn't it wrong to do this kind of optimizations ?
>
> thanks,
> Charith
>
>
>
>
>
> On Mon, Nov 21, 2011 at 8:50 AM, Charith Wickramarachchi <
> charith.dhanushka@gmail.com> wrote:
>
>> Hi ,
>>
>> This is an issue with the BE service. When the message comes to synapse
>> from the client. In its SOAP Message it has same name space declared at two
>> levels.
>>
>> At Envelope level and and inside a header. So as a result when message go
>> through synapse it will omit this redundant names space declaration.
>> But BE service will fail to process this header due to missing
>> namesspace. So its due to BEs xml phaser assumes that headers are self
>> contained and they do not see the namesspace defined at Envelope level.
>>
>> thanks,
>> Charith
>>
>>
>> On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana <
>> sanjiva@opensource.lk> wrote:
>>
>>> "So when synapse forward them to the BE service they get omitted as
>>> they are defined at SOAP Envelope level."
>>>
>>> Maybe Synapse is not serializing the headers properly?
>>>
>>> Sanjiva.
>>>
>>> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen <
>>> andreas.veithen@gmail.com> wrote:
>>>
>>>> Axiom never produces malformed XML. Who said that??
>>>>
>>>> Andreas
>>>>
>>>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
>>>> <sa...@opensource.lk> wrote:
>>>> > Isn't that a bug?
>>>> > If I declare an NS at the Envelope node then that cannot be removed if
>>>> > anyone inside uses it. If I'm serializing only the Header element(s)
>>>> then
>>>> > any in scope namespaces must be available and worst case every
>>>> element will
>>>> > re-serialize them. However under no condition is it correct to
>>>> serialize a
>>>> > child element and end up with malformed XML!
>>>> >
>>>> > Sanjiva.
>>>> >
>>>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
>>>> > <an...@gmail.com> wrote:
>>>> >>
>>>> >> Assuming that the namespace in question is not the SOAP envelope
>>>> >> namespace, instead of hacking Axiom, wouldn't it be easier to remove
>>>> >> the namespace declaration from the SOAP envelope (so that it will be
>>>> >> serialized in the SOAP header block)?
>>>> >>
>>>> >> Andreas
>>>> >>
>>>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>>>> >> <ch...@gmail.com> wrote:
>>>> >> > Hi Andreas,
>>>> >> >
>>>> >> > Issue was this causes an Error in a 3rd party web-service engine
>>>> when
>>>> >> > processing some soap headers.
>>>> >> >
>>>> >> > Scenario is this. Synapse get a soap request which contains some
>>>> >> > redundant
>>>> >> > namespace declarations at header level which are internally used
>>>> inside
>>>> >> > the
>>>> >> > headers. So when synapse forward them to the BE service they get
>>>> >> > omitted as
>>>> >> > they are defined at SOAP Envelope level.
>>>> >> >
>>>> >> > BE services header processor incorrectly assumes that headers are
>>>> self
>>>> >> > contained so this causes an error.
>>>> >> >
>>>> >> > I was wondering it may make scene to make it configurable as if we
>>>> >> > think
>>>> >> > of synapse point of view omitting redundant namespaces may not be
>>>> a
>>>> >> > good
>>>> >> > idea sometimes. Specially integrating with legacies like this.
>>>> WDYT ? (
>>>> >> > I do
>>>> >> > agree that this in pure AXIOM point of view its the correct thing
>>>> to do
>>>> >> > as
>>>> >> > it will reduce the data content that is written to the wire etc.. )
>>>> >> >
>>>> >> > Can please you point me to a place where this is done ? So that i
>>>> can
>>>> >> > hack
>>>> >> > the code for the time being for my self and later provide a patch
>>>> if
>>>> >> > devs
>>>> >> > are ok with my above idea.
>>>> >> >
>>>> >> > thanks,
>>>> >> > Charith
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>>>> >> > <an...@gmail.com>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> No, the namespace repairing performed by the serialize and
>>>> >> >> serializeAndConsume methods is not configurable.
>>>> >> >>
>>>> >> >> What is the use case for preserving a redundant namespace
>>>> declaration
>>>> >> >> on a SOAP header?
>>>> >> >>
>>>> >> >> Andreas
>>>> >> >>
>>>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>>>> >> >> <ch...@gmail.com> wrote:
>>>> >> >> > Hi devs ,
>>>> >> >> >
>>>> >> >> > When we serialize a OMElement axiom will omit redundant
>>>> namesspace
>>>> >> >> > declarations by default. Is it possible to disable this
>>>> behavior ?
>>>> >> >> > In my case i want to keep the redundant namesspace declarations
>>>> in
>>>> >> >> > SOAP
>>>> >> >> > headers.
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > thanks,
>>>> >> >> > Charith
>>>> >> >> >
>>>> >> >> > --
>>>> >> >> > Charith Dhanushka Wickramarachchi
>>>> >> >> > http://charithwiki.blogspot.com/
>>>> >> >> >
>>>> >> >> >
>>>> >> >>
>>>> >> >>
>>>> ---------------------------------------------------------------------
>>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > Charith Dhanushka Wickramarachchi
>>>> >> > http://charithwiki.blogspot.com/
>>>> >> >
>>>> >> >
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> 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/
>>>
>>>
>>
>>
>> --
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
Re: Redundant names space removal when Serializing - AXIOM
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Hi,
If xmlns:xsi is declared for saml:Assertion element then it should be
serialized - otherwise you have loss of information and that is big issue
when namespace prefixes are used inside attribute values (or element values
as well)
Not including in-scope namespaces in serialization of detached element will
be also a problem ...
my 2c,
Alek
On Mon, Nov 21, 2011 at 11:59 AM, Andreas Veithen <andreas.veithen@gmail.com
> wrote:
> On Mon, Nov 21, 2011 at 17:18, Aleksander Slominski
> <as...@cs.indiana.edu> wrote:
> > Hi,
> > from what I remember of XML and Namespaces: when you detach any child
> > element such as saml:Assertion then all in-scope namespace declared
> prefixes
> > should be copied.
>
> There is no spec that defines a general rule for this. Specs such as
> XML C14N define specific rules for this applicable in specific
> contexts.
>
> > The serializer should recognize if it is serializing a standalone or
> > embedded XML. Is there any API for it? For standalone it should print all
> > in-scope declared namesapce prefixes.
>
> What the serializer does is to generate additional namespace
> declarations if it encounters information items (elements or
> attributes) that have a prefix/namespace URI combination for which no
> namespace declaration is in scope. That covers the case of serializing
> a part of an XML document. This in general gives the expected result,
> except for cases where a namespace declaration is not visibly used,
> e.g. in an attribute value. BTW, it's the same behavior as in DOM.
>
> Anyway, this is not a relevant question because it is not related to
> the problem.
>
> > HTH,
> > Alek
> >
> > On Sun, Nov 20, 2011 at 11:31 PM, Charith Wickramarachchi
> > <ch...@gmail.com> wrote:
> >>
> >> Hi ,
> >>
> >> Looked more in to the details of whats happening. So here the problem is
> >> the element that have this redundant names space is the <saml:Assertion
> ...
> >> element which is a signed one.
> >>
> >>
> >> The incoming message to synapse looks like this.
> >>
> >> <soapenv:Envelope
> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> >> xmlns:oas="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> >> <soapenv:Header>
> >> <oas:Security>
> >> <saml:Assertion ....
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ...
> >> </saml:Assertion>
> >> </oas:Security>
> >> </soapenv:Header>
> >> ...........................
> >> </soapenv:Envelope>
> >>
> >>
> >> and output is like
> >>
> >> <soapenv:Envelope
> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> >> xmlns:oas="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> >> <soapenv:Header>
> >> <oas:Security>
> >> <saml:Assertion ...> ... </saml:Assertion>
> >> </oas:Security>
> >> </soapenv:Header>
> >>
> >>
> >> So in this case isn't it wrong to do this kind of optimizations ?
> >>
> >> thanks,
> >> Charith
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Nov 21, 2011 at 8:50 AM, Charith Wickramarachchi
> >> <ch...@gmail.com> wrote:
> >>>
> >>> Hi ,
> >>>
> >>> This is an issue with the BE service. When the message comes to synapse
> >>> from the client. In its SOAP Message it has same name space declared
> at two
> >>> levels.
> >>>
> >>> At Envelope level and and inside a header. So as a result when message
> go
> >>> through synapse it will omit this redundant names space declaration.
> >>> But BE service will fail to process this header due to missing
> >>> namesspace. So its due to BEs xml phaser assumes that headers are self
> >>> contained and they do not see the namesspace defined at Envelope level.
> >>>
> >>> thanks,
> >>> Charith
> >>>
> >>> On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana
> >>> <sa...@opensource.lk> wrote:
> >>>>
> >>>> "So when synapse forward them to the BE service they get omitted as
> >>>> they are defined at SOAP Envelope level."
> >>>> Maybe Synapse is not serializing the headers properly?
> >>>> Sanjiva.
> >>>>
> >>>> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen
> >>>> <an...@gmail.com> wrote:
> >>>>>
> >>>>> Axiom never produces malformed XML. Who said that??
> >>>>>
> >>>>> Andreas
> >>>>>
> >>>>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
> >>>>> <sa...@opensource.lk> wrote:
> >>>>> > Isn't that a bug?
> >>>>> > If I declare an NS at the Envelope node then that cannot be removed
> >>>>> > if
> >>>>> > anyone inside uses it. If I'm serializing only the Header
> element(s)
> >>>>> > then
> >>>>> > any in scope namespaces must be available and worst case every
> >>>>> > element will
> >>>>> > re-serialize them. However under no condition is it correct to
> >>>>> > serialize a
> >>>>> > child element and end up with malformed XML!
> >>>>> >
> >>>>> > Sanjiva.
> >>>>> >
> >>>>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
> >>>>> > <an...@gmail.com> wrote:
> >>>>> >>
> >>>>> >> Assuming that the namespace in question is not the SOAP envelope
> >>>>> >> namespace, instead of hacking Axiom, wouldn't it be easier to
> remove
> >>>>> >> the namespace declaration from the SOAP envelope (so that it will
> be
> >>>>> >> serialized in the SOAP header block)?
> >>>>> >>
> >>>>> >> Andreas
> >>>>> >>
> >>>>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
> >>>>> >> <ch...@gmail.com> wrote:
> >>>>> >> > Hi Andreas,
> >>>>> >> >
> >>>>> >> > Issue was this causes an Error in a 3rd party web-service engine
> >>>>> >> > when
> >>>>> >> > processing some soap headers.
> >>>>> >> >
> >>>>> >> > Scenario is this. Synapse get a soap request which contains some
> >>>>> >> > redundant
> >>>>> >> > namespace declarations at header level which are internally used
> >>>>> >> > inside
> >>>>> >> > the
> >>>>> >> > headers. So when synapse forward them to the BE service they
> get
> >>>>> >> > omitted as
> >>>>> >> > they are defined at SOAP Envelope level.
> >>>>> >> >
> >>>>> >> > BE services header processor incorrectly assumes that headers
> are
> >>>>> >> > self
> >>>>> >> > contained so this causes an error.
> >>>>> >> >
> >>>>> >> > I was wondering it may make scene to make it configurable as if
> >>>>> >> > we
> >>>>> >> > think
> >>>>> >> > of synapse point of view omitting redundant namespaces may not
> be
> >>>>> >> > a
> >>>>> >> > good
> >>>>> >> > idea sometimes. Specially integrating with legacies like this.
> >>>>> >> > WDYT ? (
> >>>>> >> > I do
> >>>>> >> > agree that this in pure AXIOM point of view its the correct
> thing
> >>>>> >> > to do
> >>>>> >> > as
> >>>>> >> > it will reduce the data content that is written to the wire
> etc..
> >>>>> >> > )
> >>>>> >> >
> >>>>> >> > Can please you point me to a place where this is done ? So that
> i
> >>>>> >> > can
> >>>>> >> > hack
> >>>>> >> > the code for the time being for my self and later provide a
> patch
> >>>>> >> > if
> >>>>> >> > devs
> >>>>> >> > are ok with my above idea.
> >>>>> >> >
> >>>>> >> > thanks,
> >>>>> >> > Charith
> >>>>> >> >
> >>>>> >> >
> >>>>> >> >
> >>>>> >> >
> >>>>> >> >
> >>>>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
> >>>>> >> > <an...@gmail.com>
> >>>>> >> > wrote:
> >>>>> >> >>
> >>>>> >> >> No, the namespace repairing performed by the serialize and
> >>>>> >> >> serializeAndConsume methods is not configurable.
> >>>>> >> >>
> >>>>> >> >> What is the use case for preserving a redundant namespace
> >>>>> >> >> declaration
> >>>>> >> >> on a SOAP header?
> >>>>> >> >>
> >>>>> >> >> Andreas
> >>>>> >> >>
> >>>>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
> >>>>> >> >> <ch...@gmail.com> wrote:
> >>>>> >> >> > Hi devs ,
> >>>>> >> >> >
> >>>>> >> >> > When we serialize a OMElement axiom will omit redundant
> >>>>> >> >> > namesspace
> >>>>> >> >> > declarations by default. Is it possible to disable this
> >>>>> >> >> > behavior ?
> >>>>> >> >> > In my case i want to keep the redundant namesspace
> declarations
> >>>>> >> >> > in
> >>>>> >> >> > SOAP
> >>>>> >> >> > headers.
> >>>>> >> >> >
> >>>>> >> >> >
> >>>>> >> >> > thanks,
> >>>>> >> >> > Charith
> >>>>> >> >> >
> >>>>> >> >> > --
> >>>>> >> >> > Charith Dhanushka Wickramarachchi
> >>>>> >> >> > http://charithwiki.blogspot.com/
> >>>>> >> >> >
> >>>>> >> >> >
> >>>>> >> >>
> >>>>> >> >>
> >>>>> >> >>
> ---------------------------------------------------------------------
> >>>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> >>>>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
> >>>>> >> >>
> >>>>> >> >
> >>>>> >> >
> >>>>> >> >
> >>>>> >> > --
> >>>>> >> > Charith Dhanushka Wickramarachchi
> >>>>> >> > http://charithwiki.blogspot.com/
> >>>>> >> >
> >>>>> >> >
> >>>>> >>
> >>>>> >>
> >>>>> >>
> ---------------------------------------------------------------------
> >>>>> >> 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/
> >>>
> >>>
> >>>
> >>> --
> >>> Charith Dhanushka Wickramarachchi
> >>> http://charithwiki.blogspot.com/
> >>>
> >>
> >>
> >>
> >> --
> >> Charith Dhanushka Wickramarachchi
> >> http://charithwiki.blogspot.com/
> >>
> >
> >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
>
--
The best way to predict the future is to invent it - Alan Kay
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, Nov 21, 2011 at 17:18, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
> Hi,
> from what I remember of XML and Namespaces: when you detach any child
> element such as saml:Assertion then all in-scope namespace declared prefixes
> should be copied.
There is no spec that defines a general rule for this. Specs such as
XML C14N define specific rules for this applicable in specific
contexts.
> The serializer should recognize if it is serializing a standalone or
> embedded XML. Is there any API for it? For standalone it should print all
> in-scope declared namesapce prefixes.
What the serializer does is to generate additional namespace
declarations if it encounters information items (elements or
attributes) that have a prefix/namespace URI combination for which no
namespace declaration is in scope. That covers the case of serializing
a part of an XML document. This in general gives the expected result,
except for cases where a namespace declaration is not visibly used,
e.g. in an attribute value. BTW, it's the same behavior as in DOM.
Anyway, this is not a relevant question because it is not related to
the problem.
> HTH,
> Alek
>
> On Sun, Nov 20, 2011 at 11:31 PM, Charith Wickramarachchi
> <ch...@gmail.com> wrote:
>>
>> Hi ,
>>
>> Looked more in to the details of whats happening. So here the problem is
>> the element that have this redundant names space is the <saml:Assertion ...
>> element which is a signed one.
>>
>>
>> The incoming message to synapse looks like this.
>>
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <soapenv:Header>
>> <oas:Security>
>> <saml:Assertion ....
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ...
>> </saml:Assertion>
>> </oas:Security>
>> </soapenv:Header>
>> ...........................
>> </soapenv:Envelope>
>>
>>
>> and output is like
>>
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <soapenv:Header>
>> <oas:Security>
>> <saml:Assertion ...> ... </saml:Assertion>
>> </oas:Security>
>> </soapenv:Header>
>>
>>
>> So in this case isn't it wrong to do this kind of optimizations ?
>>
>> thanks,
>> Charith
>>
>>
>>
>>
>>
>> On Mon, Nov 21, 2011 at 8:50 AM, Charith Wickramarachchi
>> <ch...@gmail.com> wrote:
>>>
>>> Hi ,
>>>
>>> This is an issue with the BE service. When the message comes to synapse
>>> from the client. In its SOAP Message it has same name space declared at two
>>> levels.
>>>
>>> At Envelope level and and inside a header. So as a result when message go
>>> through synapse it will omit this redundant names space declaration.
>>> But BE service will fail to process this header due to missing
>>> namesspace. So its due to BEs xml phaser assumes that headers are self
>>> contained and they do not see the namesspace defined at Envelope level.
>>>
>>> thanks,
>>> Charith
>>>
>>> On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana
>>> <sa...@opensource.lk> wrote:
>>>>
>>>> "So when synapse forward them to the BE service they get omitted as
>>>> they are defined at SOAP Envelope level."
>>>> Maybe Synapse is not serializing the headers properly?
>>>> Sanjiva.
>>>>
>>>> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen
>>>> <an...@gmail.com> wrote:
>>>>>
>>>>> Axiom never produces malformed XML. Who said that??
>>>>>
>>>>> Andreas
>>>>>
>>>>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
>>>>> <sa...@opensource.lk> wrote:
>>>>> > Isn't that a bug?
>>>>> > If I declare an NS at the Envelope node then that cannot be removed
>>>>> > if
>>>>> > anyone inside uses it. If I'm serializing only the Header element(s)
>>>>> > then
>>>>> > any in scope namespaces must be available and worst case every
>>>>> > element will
>>>>> > re-serialize them. However under no condition is it correct to
>>>>> > serialize a
>>>>> > child element and end up with malformed XML!
>>>>> >
>>>>> > Sanjiva.
>>>>> >
>>>>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
>>>>> > <an...@gmail.com> wrote:
>>>>> >>
>>>>> >> Assuming that the namespace in question is not the SOAP envelope
>>>>> >> namespace, instead of hacking Axiom, wouldn't it be easier to remove
>>>>> >> the namespace declaration from the SOAP envelope (so that it will be
>>>>> >> serialized in the SOAP header block)?
>>>>> >>
>>>>> >> Andreas
>>>>> >>
>>>>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>>>>> >> <ch...@gmail.com> wrote:
>>>>> >> > Hi Andreas,
>>>>> >> >
>>>>> >> > Issue was this causes an Error in a 3rd party web-service engine
>>>>> >> > when
>>>>> >> > processing some soap headers.
>>>>> >> >
>>>>> >> > Scenario is this. Synapse get a soap request which contains some
>>>>> >> > redundant
>>>>> >> > namespace declarations at header level which are internally used
>>>>> >> > inside
>>>>> >> > the
>>>>> >> > headers. So when synapse forward them to the BE service they get
>>>>> >> > omitted as
>>>>> >> > they are defined at SOAP Envelope level.
>>>>> >> >
>>>>> >> > BE services header processor incorrectly assumes that headers are
>>>>> >> > self
>>>>> >> > contained so this causes an error.
>>>>> >> >
>>>>> >> > I was wondering it may make scene to make it configurable as if
>>>>> >> > we
>>>>> >> > think
>>>>> >> > of synapse point of view omitting redundant namespaces may not be
>>>>> >> > a
>>>>> >> > good
>>>>> >> > idea sometimes. Specially integrating with legacies like this.
>>>>> >> > WDYT ? (
>>>>> >> > I do
>>>>> >> > agree that this in pure AXIOM point of view its the correct thing
>>>>> >> > to do
>>>>> >> > as
>>>>> >> > it will reduce the data content that is written to the wire etc..
>>>>> >> > )
>>>>> >> >
>>>>> >> > Can please you point me to a place where this is done ? So that i
>>>>> >> > can
>>>>> >> > hack
>>>>> >> > the code for the time being for my self and later provide a patch
>>>>> >> > if
>>>>> >> > devs
>>>>> >> > are ok with my above idea.
>>>>> >> >
>>>>> >> > thanks,
>>>>> >> > Charith
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>>>>> >> > <an...@gmail.com>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> No, the namespace repairing performed by the serialize and
>>>>> >> >> serializeAndConsume methods is not configurable.
>>>>> >> >>
>>>>> >> >> What is the use case for preserving a redundant namespace
>>>>> >> >> declaration
>>>>> >> >> on a SOAP header?
>>>>> >> >>
>>>>> >> >> Andreas
>>>>> >> >>
>>>>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>>>>> >> >> <ch...@gmail.com> wrote:
>>>>> >> >> > Hi devs ,
>>>>> >> >> >
>>>>> >> >> > When we serialize a OMElement axiom will omit redundant
>>>>> >> >> > namesspace
>>>>> >> >> > declarations by default. Is it possible to disable this
>>>>> >> >> > behavior ?
>>>>> >> >> > In my case i want to keep the redundant namesspace declarations
>>>>> >> >> > in
>>>>> >> >> > SOAP
>>>>> >> >> > headers.
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > thanks,
>>>>> >> >> > Charith
>>>>> >> >> >
>>>>> >> >> > --
>>>>> >> >> > Charith Dhanushka Wickramarachchi
>>>>> >> >> > http://charithwiki.blogspot.com/
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> ---------------------------------------------------------------------
>>>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>>>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > Charith Dhanushka Wickramarachchi
>>>>> >> > http://charithwiki.blogspot.com/
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >> 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/
>>>
>>>
>>>
>>> --
>>> Charith Dhanushka Wickramarachchi
>>> http://charithwiki.blogspot.com/
>>>
>>
>>
>>
>> --
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Redundant names space removal when Serializing - AXIOM
Posted by Deepal jayasinghe <de...@gmail.com>.
On 11/21/2011 11:18 AM, Aleksander Slominski wrote:
> Hi,
>
> from what I remember of XML and Namespaces: when you detach any child
> element such as saml:Assertion then all in-scope namespace declared
> prefixes should be copied.
IIRC, Axiom did exactly what you mentioned, however I am not sure how it
works today. (did not use Axiom for years now).
Deepal
>
> The serializer should recognize if it is serializing a standalone or
> embedded XML. Is there any API for it? For standalone it should print
> all in-scope declared namesapce prefixes.
>
> HTH,
>
> Alek
>
> On Sun, Nov 20, 2011 at 11:31 PM, Charith Wickramarachchi
> <charith.dhanushka@gmail.com <ma...@gmail.com>> wrote:
>
> Hi ,
>
> Looked more in to the details of whats happening. So here the
> problem is the element that have this redundant names space is the
> <saml:Assertion ... element which is a signed one.
>
>
> The incoming message to synapse looks like this.
>
> <soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Header>
> <oas:Security>
> <saml:Assertion ....
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ...
> </saml:Assertion>
> </oas:Security>
> </soapenv:Header>
> ...........................
> </soapenv:Envelope>
>
>
> and output is like
>
> <soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Header>
> <oas:Security>
> <saml:Assertion ...> ... </saml:Assertion>
> </oas:Security>
> </soapenv:Header>
>
>
> So in this case isn't it wrong to do this kind of optimizations ?
>
> thanks,
> Charith
>
>
>
>
>
> On Mon, Nov 21, 2011 at 8:50 AM, Charith Wickramarachchi
> <charith.dhanushka@gmail.com <ma...@gmail.com>>
> wrote:
>
> Hi ,
>
> This is an issue with the BE service. When the message comes
> to synapse from the client. In its SOAP Message it has same
> name space declared at two levels.
>
> At Envelope level and and inside a header. So as a result when
> message go through synapse it will omit this redundant names
> space declaration.
> But BE service will fail to process this header due to
> missing namesspace. So its due to BEs xml phaser assumes that
> headers are self contained and they do not see the namesspace
> defined at Envelope level.
>
> thanks,
> Charith
>
>
> On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana
> <sanjiva@opensource.lk <ma...@opensource.lk>> wrote:
>
> "So when synapse forward them to the BE service they get
> omitted as they are defined at SOAP Envelope level."
>
> Maybe Synapse is not serializing the headers properly?
>
> Sanjiva.
>
> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen
> <andreas.veithen@gmail.com
> <ma...@gmail.com>> wrote:
>
> Axiom never produces malformed XML. Who said that??
>
> Andreas
>
> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
> <sanjiva@opensource.lk <ma...@opensource.lk>>
> wrote:
> > Isn't that a bug?
> > If I declare an NS at the Envelope node then that
> cannot be removed if
> > anyone inside uses it. If I'm serializing only the
> Header element(s) then
> > any in scope namespaces must be available and worst
> case every element will
> > re-serialize them. However under no condition is it
> correct to serialize a
> > child element and end up with malformed XML!
> >
> > Sanjiva.
> >
> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
> > <andreas.veithen@gmail.com
> <ma...@gmail.com>> wrote:
> >>
> >> Assuming that the namespace in question is not the
> SOAP envelope
> >> namespace, instead of hacking Axiom, wouldn't it be
> easier to remove
> >> the namespace declaration from the SOAP envelope
> (so that it will be
> >> serialized in the SOAP header block)?
> >>
> >> Andreas
> >>
> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
> >> <charith.dhanushka@gmail.com
> <ma...@gmail.com>> wrote:
> >> > Hi Andreas,
> >> >
> >> > Issue was this causes an Error in a 3rd party
> web-service engine when
> >> > processing some soap headers.
> >> >
> >> > Scenario is this. Synapse get a soap request
> which contains some
> >> > redundant
> >> > namespace declarations at header level which are
> internally used inside
> >> > the
> >> > headers. So when synapse forward them to the BE
> service they get
> >> > omitted as
> >> > they are defined at SOAP Envelope level.
> >> >
> >> > BE services header processor incorrectly assumes
> that headers are self
> >> > contained so this causes an error.
> >> >
> >> > I was wondering it may make scene to make it
> configurable as if we
> >> > think
> >> > of synapse point of view omitting redundant
> namespaces may not be a
> >> > good
> >> > idea sometimes. Specially integrating with
> legacies like this. WDYT ? (
> >> > I do
> >> > agree that this in pure AXIOM point of view its
> the correct thing to do
> >> > as
> >> > it will reduce the data content that is written
> to the wire etc.. )
> >> >
> >> > Can please you point me to a place where this is
> done ? So that i can
> >> > hack
> >> > the code for the time being for my self and later
> provide a patch if
> >> > devs
> >> > are ok with my above idea.
> >> >
> >> > thanks,
> >> > Charith
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
> >> > <andreas.veithen@gmail.com
> <ma...@gmail.com>>
> >> > wrote:
> >> >>
> >> >> No, the namespace repairing performed by the
> serialize and
> >> >> serializeAndConsume methods is not configurable.
> >> >>
> >> >> What is the use case for preserving a redundant
> namespace declaration
> >> >> on a SOAP header?
> >> >>
> >> >> Andreas
> >> >>
> >> >> On Fri, Nov 18, 2011 at 03:23, Charith
> Wickramarachchi
> >> >> <charith.dhanushka@gmail.com
> <ma...@gmail.com>> wrote:
> >> >> > Hi devs ,
> >> >> >
> >> >> > When we serialize a OMElement axiom will omit
> redundant namesspace
> >> >> > declarations by default. Is it possible to
> disable this behavior ?
> >> >> > In my case i want to keep the redundant
> namesspace declarations in
> >> >> > SOAP
> >> >> > headers.
> >> >> >
> >> >> >
> >> >> > thanks,
> >> >> > Charith
> >> >> >
> >> >> > --
> >> >> > Charith Dhanushka Wickramarachchi
> >> >> > http://charithwiki.blogspot.com/
> >> >> >
> >> >> >
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail:
> dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> >> >> For additional commands, e-mail:
> dev-help@ws.apache.org <ma...@ws.apache.org>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Charith Dhanushka Wickramarachchi
> >> > http://charithwiki.blogspot.com/
> >> >
> >> >
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> >> For additional commands, e-mail:
> dev-help@ws.apache.org <ma...@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
> <ma...@ws.apache.org>
> For additional commands, e-mail:
> dev-help@ws.apache.org <ma...@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/
>
>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
Re: Redundant names space removal when Serializing - AXIOM
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Hi,
from what I remember of XML and Namespaces: when you detach any child
element such as saml:Assertion then all in-scope namespace declared
prefixes should be copied.
The serializer should recognize if it is serializing a standalone or
embedded XML. Is there any API for it? For standalone it should print all
in-scope declared namesapce prefixes.
HTH,
Alek
On Sun, Nov 20, 2011 at 11:31 PM, Charith Wickramarachchi <
charith.dhanushka@gmail.com> wrote:
> Hi ,
>
> Looked more in to the details of whats happening. So here the problem is
> the element that have this redundant names space is the <saml:Assertion
> ... element which is a signed one.
>
>
> The incoming message to synapse looks like this.
>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:oas="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Header>
> <oas:Security>
> <saml:Assertion .... xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> ... </saml:Assertion>
> </oas:Security>
> </soapenv:Header>
> ...........................
> </soapenv:Envelope>
>
>
> and output is like
>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:oas="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Header>
> <oas:Security>
> <saml:Assertion ...> ... </saml:Assertion>
> </oas:Security>
> </soapenv:Header>
>
>
> So in this case isn't it wrong to do this kind of optimizations ?
>
> thanks,
> Charith
>
>
>
>
>
> On Mon, Nov 21, 2011 at 8:50 AM, Charith Wickramarachchi <
> charith.dhanushka@gmail.com> wrote:
>
>> Hi ,
>>
>> This is an issue with the BE service. When the message comes to synapse
>> from the client. In its SOAP Message it has same name space declared at two
>> levels.
>>
>> At Envelope level and and inside a header. So as a result when message go
>> through synapse it will omit this redundant names space declaration.
>> But BE service will fail to process this header due to missing
>> namesspace. So its due to BEs xml phaser assumes that headers are self
>> contained and they do not see the namesspace defined at Envelope level.
>>
>> thanks,
>> Charith
>>
>>
>> On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana <
>> sanjiva@opensource.lk> wrote:
>>
>>> "So when synapse forward them to the BE service they get omitted as
>>> they are defined at SOAP Envelope level."
>>>
>>> Maybe Synapse is not serializing the headers properly?
>>>
>>> Sanjiva.
>>>
>>> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen <
>>> andreas.veithen@gmail.com> wrote:
>>>
>>>> Axiom never produces malformed XML. Who said that??
>>>>
>>>> Andreas
>>>>
>>>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
>>>> <sa...@opensource.lk> wrote:
>>>> > Isn't that a bug?
>>>> > If I declare an NS at the Envelope node then that cannot be removed if
>>>> > anyone inside uses it. If I'm serializing only the Header element(s)
>>>> then
>>>> > any in scope namespaces must be available and worst case every
>>>> element will
>>>> > re-serialize them. However under no condition is it correct to
>>>> serialize a
>>>> > child element and end up with malformed XML!
>>>> >
>>>> > Sanjiva.
>>>> >
>>>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
>>>> > <an...@gmail.com> wrote:
>>>> >>
>>>> >> Assuming that the namespace in question is not the SOAP envelope
>>>> >> namespace, instead of hacking Axiom, wouldn't it be easier to remove
>>>> >> the namespace declaration from the SOAP envelope (so that it will be
>>>> >> serialized in the SOAP header block)?
>>>> >>
>>>> >> Andreas
>>>> >>
>>>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>>>> >> <ch...@gmail.com> wrote:
>>>> >> > Hi Andreas,
>>>> >> >
>>>> >> > Issue was this causes an Error in a 3rd party web-service engine
>>>> when
>>>> >> > processing some soap headers.
>>>> >> >
>>>> >> > Scenario is this. Synapse get a soap request which contains some
>>>> >> > redundant
>>>> >> > namespace declarations at header level which are internally used
>>>> inside
>>>> >> > the
>>>> >> > headers. So when synapse forward them to the BE service they get
>>>> >> > omitted as
>>>> >> > they are defined at SOAP Envelope level.
>>>> >> >
>>>> >> > BE services header processor incorrectly assumes that headers are
>>>> self
>>>> >> > contained so this causes an error.
>>>> >> >
>>>> >> > I was wondering it may make scene to make it configurable as if we
>>>> >> > think
>>>> >> > of synapse point of view omitting redundant namespaces may not be
>>>> a
>>>> >> > good
>>>> >> > idea sometimes. Specially integrating with legacies like this.
>>>> WDYT ? (
>>>> >> > I do
>>>> >> > agree that this in pure AXIOM point of view its the correct thing
>>>> to do
>>>> >> > as
>>>> >> > it will reduce the data content that is written to the wire etc.. )
>>>> >> >
>>>> >> > Can please you point me to a place where this is done ? So that i
>>>> can
>>>> >> > hack
>>>> >> > the code for the time being for my self and later provide a patch
>>>> if
>>>> >> > devs
>>>> >> > are ok with my above idea.
>>>> >> >
>>>> >> > thanks,
>>>> >> > Charith
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>>>> >> > <an...@gmail.com>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> No, the namespace repairing performed by the serialize and
>>>> >> >> serializeAndConsume methods is not configurable.
>>>> >> >>
>>>> >> >> What is the use case for preserving a redundant namespace
>>>> declaration
>>>> >> >> on a SOAP header?
>>>> >> >>
>>>> >> >> Andreas
>>>> >> >>
>>>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>>>> >> >> <ch...@gmail.com> wrote:
>>>> >> >> > Hi devs ,
>>>> >> >> >
>>>> >> >> > When we serialize a OMElement axiom will omit redundant
>>>> namesspace
>>>> >> >> > declarations by default. Is it possible to disable this
>>>> behavior ?
>>>> >> >> > In my case i want to keep the redundant namesspace declarations
>>>> in
>>>> >> >> > SOAP
>>>> >> >> > headers.
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > thanks,
>>>> >> >> > Charith
>>>> >> >> >
>>>> >> >> > --
>>>> >> >> > Charith Dhanushka Wickramarachchi
>>>> >> >> > http://charithwiki.blogspot.com/
>>>> >> >> >
>>>> >> >> >
>>>> >> >>
>>>> >> >>
>>>> ---------------------------------------------------------------------
>>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > Charith Dhanushka Wickramarachchi
>>>> >> > http://charithwiki.blogspot.com/
>>>> >> >
>>>> >> >
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> 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/
>>>
>>>
>>
>>
>> --
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: Redundant names space removal when Serializing - AXIOM
Posted by Charith Wickramarachchi <ch...@gmail.com>.
Hi ,
Looked more in to the details of whats happening. So here the problem is
the element that have this redundant names space is the
<saml:Assertion ...element which is a signed one.
The incoming message to synapse looks like this.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:oas="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<oas:Security>
<saml:Assertion .... xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
... </saml:Assertion>
</oas:Security>
</soapenv:Header>
...........................
</soapenv:Envelope>
and output is like
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:oas="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<oas:Security>
<saml:Assertion ...> ... </saml:Assertion>
</oas:Security>
</soapenv:Header>
So in this case isn't it wrong to do this kind of optimizations ?
thanks,
Charith
On Mon, Nov 21, 2011 at 8:50 AM, Charith Wickramarachchi <
charith.dhanushka@gmail.com> wrote:
> Hi ,
>
> This is an issue with the BE service. When the message comes to synapse
> from the client. In its SOAP Message it has same name space declared at two
> levels.
>
> At Envelope level and and inside a header. So as a result when message go
> through synapse it will omit this redundant names space declaration.
> But BE service will fail to process this header due to missing
> namesspace. So its due to BEs xml phaser assumes that headers are self
> contained and they do not see the namesspace defined at Envelope level.
>
> thanks,
> Charith
>
>
> On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana <
> sanjiva@opensource.lk> wrote:
>
>> "So when synapse forward them to the BE service they get omitted as
>> they are defined at SOAP Envelope level."
>>
>> Maybe Synapse is not serializing the headers properly?
>>
>> Sanjiva.
>>
>> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen <
>> andreas.veithen@gmail.com> wrote:
>>
>>> Axiom never produces malformed XML. Who said that??
>>>
>>> Andreas
>>>
>>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
>>> <sa...@opensource.lk> wrote:
>>> > Isn't that a bug?
>>> > If I declare an NS at the Envelope node then that cannot be removed if
>>> > anyone inside uses it. If I'm serializing only the Header element(s)
>>> then
>>> > any in scope namespaces must be available and worst case every element
>>> will
>>> > re-serialize them. However under no condition is it correct to
>>> serialize a
>>> > child element and end up with malformed XML!
>>> >
>>> > Sanjiva.
>>> >
>>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
>>> > <an...@gmail.com> wrote:
>>> >>
>>> >> Assuming that the namespace in question is not the SOAP envelope
>>> >> namespace, instead of hacking Axiom, wouldn't it be easier to remove
>>> >> the namespace declaration from the SOAP envelope (so that it will be
>>> >> serialized in the SOAP header block)?
>>> >>
>>> >> Andreas
>>> >>
>>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>>> >> <ch...@gmail.com> wrote:
>>> >> > Hi Andreas,
>>> >> >
>>> >> > Issue was this causes an Error in a 3rd party web-service engine
>>> when
>>> >> > processing some soap headers.
>>> >> >
>>> >> > Scenario is this. Synapse get a soap request which contains some
>>> >> > redundant
>>> >> > namespace declarations at header level which are internally used
>>> inside
>>> >> > the
>>> >> > headers. So when synapse forward them to the BE service they get
>>> >> > omitted as
>>> >> > they are defined at SOAP Envelope level.
>>> >> >
>>> >> > BE services header processor incorrectly assumes that headers are
>>> self
>>> >> > contained so this causes an error.
>>> >> >
>>> >> > I was wondering it may make scene to make it configurable as if we
>>> >> > think
>>> >> > of synapse point of view omitting redundant namespaces may not be a
>>> >> > good
>>> >> > idea sometimes. Specially integrating with legacies like this. WDYT
>>> ? (
>>> >> > I do
>>> >> > agree that this in pure AXIOM point of view its the correct thing
>>> to do
>>> >> > as
>>> >> > it will reduce the data content that is written to the wire etc.. )
>>> >> >
>>> >> > Can please you point me to a place where this is done ? So that i
>>> can
>>> >> > hack
>>> >> > the code for the time being for my self and later provide a patch if
>>> >> > devs
>>> >> > are ok with my above idea.
>>> >> >
>>> >> > thanks,
>>> >> > Charith
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>>> >> > <an...@gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> No, the namespace repairing performed by the serialize and
>>> >> >> serializeAndConsume methods is not configurable.
>>> >> >>
>>> >> >> What is the use case for preserving a redundant namespace
>>> declaration
>>> >> >> on a SOAP header?
>>> >> >>
>>> >> >> Andreas
>>> >> >>
>>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>>> >> >> <ch...@gmail.com> wrote:
>>> >> >> > Hi devs ,
>>> >> >> >
>>> >> >> > When we serialize a OMElement axiom will omit redundant
>>> namesspace
>>> >> >> > declarations by default. Is it possible to disable this behavior
>>> ?
>>> >> >> > In my case i want to keep the redundant namesspace declarations
>>> in
>>> >> >> > SOAP
>>> >> >> > headers.
>>> >> >> >
>>> >> >> >
>>> >> >> > thanks,
>>> >> >> > Charith
>>> >> >> >
>>> >> >> > --
>>> >> >> > Charith Dhanushka Wickramarachchi
>>> >> >> > http://charithwiki.blogspot.com/
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >>
>>> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Charith Dhanushka Wickramarachchi
>>> >> > http://charithwiki.blogspot.com/
>>> >> >
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> 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/
>>
>>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Charith Wickramarachchi <ch...@gmail.com>.
Hi ,
This is an issue with the BE service. When the message comes to synapse
from the client. In its SOAP Message it has same name space declared at two
levels.
At Envelope level and and inside a header. So as a result when message go
through synapse it will omit this redundant names space declaration.
But BE service will fail to process this header due to missing namesspace.
So its due to BEs xml phaser assumes that headers are self contained and
they do not see the namesspace defined at Envelope level.
thanks,
Charith
On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana <sanjiva@opensource.lk
> wrote:
> "So when synapse forward them to the BE service they get omitted as they
> are defined at SOAP Envelope level."
>
> Maybe Synapse is not serializing the headers properly?
>
> Sanjiva.
>
> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen <
> andreas.veithen@gmail.com> wrote:
>
>> Axiom never produces malformed XML. Who said that??
>>
>> Andreas
>>
>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
>> <sa...@opensource.lk> wrote:
>> > Isn't that a bug?
>> > If I declare an NS at the Envelope node then that cannot be removed if
>> > anyone inside uses it. If I'm serializing only the Header element(s)
>> then
>> > any in scope namespaces must be available and worst case every element
>> will
>> > re-serialize them. However under no condition is it correct to
>> serialize a
>> > child element and end up with malformed XML!
>> >
>> > Sanjiva.
>> >
>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
>> > <an...@gmail.com> wrote:
>> >>
>> >> Assuming that the namespace in question is not the SOAP envelope
>> >> namespace, instead of hacking Axiom, wouldn't it be easier to remove
>> >> the namespace declaration from the SOAP envelope (so that it will be
>> >> serialized in the SOAP header block)?
>> >>
>> >> Andreas
>> >>
>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>> >> <ch...@gmail.com> wrote:
>> >> > Hi Andreas,
>> >> >
>> >> > Issue was this causes an Error in a 3rd party web-service engine when
>> >> > processing some soap headers.
>> >> >
>> >> > Scenario is this. Synapse get a soap request which contains some
>> >> > redundant
>> >> > namespace declarations at header level which are internally used
>> inside
>> >> > the
>> >> > headers. So when synapse forward them to the BE service they get
>> >> > omitted as
>> >> > they are defined at SOAP Envelope level.
>> >> >
>> >> > BE services header processor incorrectly assumes that headers are
>> self
>> >> > contained so this causes an error.
>> >> >
>> >> > I was wondering it may make scene to make it configurable as if we
>> >> > think
>> >> > of synapse point of view omitting redundant namespaces may not be a
>> >> > good
>> >> > idea sometimes. Specially integrating with legacies like this. WDYT
>> ? (
>> >> > I do
>> >> > agree that this in pure AXIOM point of view its the correct thing to
>> do
>> >> > as
>> >> > it will reduce the data content that is written to the wire etc.. )
>> >> >
>> >> > Can please you point me to a place where this is done ? So that i can
>> >> > hack
>> >> > the code for the time being for my self and later provide a patch if
>> >> > devs
>> >> > are ok with my above idea.
>> >> >
>> >> > thanks,
>> >> > Charith
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> No, the namespace repairing performed by the serialize and
>> >> >> serializeAndConsume methods is not configurable.
>> >> >>
>> >> >> What is the use case for preserving a redundant namespace
>> declaration
>> >> >> on a SOAP header?
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>> >> >> <ch...@gmail.com> wrote:
>> >> >> > Hi devs ,
>> >> >> >
>> >> >> > When we serialize a OMElement axiom will omit redundant namesspace
>> >> >> > declarations by default. Is it possible to disable this behavior ?
>> >> >> > In my case i want to keep the redundant namesspace declarations in
>> >> >> > SOAP
>> >> >> > headers.
>> >> >> >
>> >> >> >
>> >> >> > thanks,
>> >> >> > Charith
>> >> >> >
>> >> >> > --
>> >> >> > Charith Dhanushka Wickramarachchi
>> >> >> > http://charithwiki.blogspot.com/
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Charith Dhanushka Wickramarachchi
>> >> > http://charithwiki.blogspot.com/
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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/
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"So when synapse forward them to the BE service they get omitted as they
are defined at SOAP Envelope level."
Maybe Synapse is not serializing the headers properly?
Sanjiva.
On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen <andreas.veithen@gmail.com
> wrote:
> Axiom never produces malformed XML. Who said that??
>
> Andreas
>
> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
> <sa...@opensource.lk> wrote:
> > Isn't that a bug?
> > If I declare an NS at the Envelope node then that cannot be removed if
> > anyone inside uses it. If I'm serializing only the Header element(s) then
> > any in scope namespaces must be available and worst case every element
> will
> > re-serialize them. However under no condition is it correct to serialize
> a
> > child element and end up with malformed XML!
> >
> > Sanjiva.
> >
> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
> > <an...@gmail.com> wrote:
> >>
> >> Assuming that the namespace in question is not the SOAP envelope
> >> namespace, instead of hacking Axiom, wouldn't it be easier to remove
> >> the namespace declaration from the SOAP envelope (so that it will be
> >> serialized in the SOAP header block)?
> >>
> >> Andreas
> >>
> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
> >> <ch...@gmail.com> wrote:
> >> > Hi Andreas,
> >> >
> >> > Issue was this causes an Error in a 3rd party web-service engine when
> >> > processing some soap headers.
> >> >
> >> > Scenario is this. Synapse get a soap request which contains some
> >> > redundant
> >> > namespace declarations at header level which are internally used
> inside
> >> > the
> >> > headers. So when synapse forward them to the BE service they get
> >> > omitted as
> >> > they are defined at SOAP Envelope level.
> >> >
> >> > BE services header processor incorrectly assumes that headers are self
> >> > contained so this causes an error.
> >> >
> >> > I was wondering it may make scene to make it configurable as if we
> >> > think
> >> > of synapse point of view omitting redundant namespaces may not be a
> >> > good
> >> > idea sometimes. Specially integrating with legacies like this. WDYT ?
> (
> >> > I do
> >> > agree that this in pure AXIOM point of view its the correct thing to
> do
> >> > as
> >> > it will reduce the data content that is written to the wire etc.. )
> >> >
> >> > Can please you point me to a place where this is done ? So that i can
> >> > hack
> >> > the code for the time being for my self and later provide a patch if
> >> > devs
> >> > are ok with my above idea.
> >> >
> >> > thanks,
> >> > Charith
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> No, the namespace repairing performed by the serialize and
> >> >> serializeAndConsume methods is not configurable.
> >> >>
> >> >> What is the use case for preserving a redundant namespace declaration
> >> >> on a SOAP header?
> >> >>
> >> >> Andreas
> >> >>
> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
> >> >> <ch...@gmail.com> wrote:
> >> >> > Hi devs ,
> >> >> >
> >> >> > When we serialize a OMElement axiom will omit redundant namesspace
> >> >> > declarations by default. Is it possible to disable this behavior ?
> >> >> > In my case i want to keep the redundant namesspace declarations in
> >> >> > SOAP
> >> >> > headers.
> >> >> >
> >> >> >
> >> >> > thanks,
> >> >> > Charith
> >> >> >
> >> >> > --
> >> >> > Charith Dhanushka Wickramarachchi
> >> >> > http://charithwiki.blogspot.com/
> >> >> >
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: dev-help@ws.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Charith Dhanushka Wickramarachchi
> >> > http://charithwiki.blogspot.com/
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
Axiom never produces malformed XML. Who said that??
Andreas
On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> Isn't that a bug?
> If I declare an NS at the Envelope node then that cannot be removed if
> anyone inside uses it. If I'm serializing only the Header element(s) then
> any in scope namespaces must be available and worst case every element will
> re-serialize them. However under no condition is it correct to serialize a
> child element and end up with malformed XML!
>
> Sanjiva.
>
> On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
> <an...@gmail.com> wrote:
>>
>> Assuming that the namespace in question is not the SOAP envelope
>> namespace, instead of hacking Axiom, wouldn't it be easier to remove
>> the namespace declaration from the SOAP envelope (so that it will be
>> serialized in the SOAP header block)?
>>
>> Andreas
>>
>> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>> <ch...@gmail.com> wrote:
>> > Hi Andreas,
>> >
>> > Issue was this causes an Error in a 3rd party web-service engine when
>> > processing some soap headers.
>> >
>> > Scenario is this. Synapse get a soap request which contains some
>> > redundant
>> > namespace declarations at header level which are internally used inside
>> > the
>> > headers. So when synapse forward them to the BE service they get
>> > omitted as
>> > they are defined at SOAP Envelope level.
>> >
>> > BE services header processor incorrectly assumes that headers are self
>> > contained so this causes an error.
>> >
>> > I was wondering it may make scene to make it configurable as if we
>> > think
>> > of synapse point of view omitting redundant namespaces may not be a
>> > good
>> > idea sometimes. Specially integrating with legacies like this. WDYT ? (
>> > I do
>> > agree that this in pure AXIOM point of view its the correct thing to do
>> > as
>> > it will reduce the data content that is written to the wire etc.. )
>> >
>> > Can please you point me to a place where this is done ? So that i can
>> > hack
>> > the code for the time being for my self and later provide a patch if
>> > devs
>> > are ok with my above idea.
>> >
>> > thanks,
>> > Charith
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> No, the namespace repairing performed by the serialize and
>> >> serializeAndConsume methods is not configurable.
>> >>
>> >> What is the use case for preserving a redundant namespace declaration
>> >> on a SOAP header?
>> >>
>> >> Andreas
>> >>
>> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>> >> <ch...@gmail.com> wrote:
>> >> > Hi devs ,
>> >> >
>> >> > When we serialize a OMElement axiom will omit redundant namesspace
>> >> > declarations by default. Is it possible to disable this behavior ?
>> >> > In my case i want to keep the redundant namesspace declarations in
>> >> > SOAP
>> >> > headers.
>> >> >
>> >> >
>> >> > thanks,
>> >> > Charith
>> >> >
>> >> > --
>> >> > Charith Dhanushka Wickramarachchi
>> >> > http://charithwiki.blogspot.com/
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: dev-help@ws.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Charith Dhanushka Wickramarachchi
>> > http://charithwiki.blogspot.com/
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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
Re: Redundant names space removal when Serializing - AXIOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Isn't that a bug?
If I declare an NS at the Envelope node then that cannot be removed if
anyone inside uses it. If I'm serializing only the Header element(s) then
any in scope namespaces must be available and worst case every element will
re-serialize them. However under no condition is it correct to serialize a
child element and end up with malformed XML!
Sanjiva.
On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen <andreas.veithen@gmail.com
> wrote:
> Assuming that the namespace in question is not the SOAP envelope
> namespace, instead of hacking Axiom, wouldn't it be easier to remove
> the namespace declaration from the SOAP envelope (so that it will be
> serialized in the SOAP header block)?
>
> Andreas
>
> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
> <ch...@gmail.com> wrote:
> > Hi Andreas,
> >
> > Issue was this causes an Error in a 3rd party web-service engine when
> > processing some soap headers.
> >
> > Scenario is this. Synapse get a soap request which contains some
> redundant
> > namespace declarations at header level which are internally used inside
> the
> > headers. So when synapse forward them to the BE service they get
> omitted as
> > they are defined at SOAP Envelope level.
> >
> > BE services header processor incorrectly assumes that headers are self
> > contained so this causes an error.
> >
> > I was wondering it may make scene to make it configurable as if we think
> > of synapse point of view omitting redundant namespaces may not be a good
> > idea sometimes. Specially integrating with legacies like this. WDYT ? (
> I do
> > agree that this in pure AXIOM point of view its the correct thing to do
> as
> > it will reduce the data content that is written to the wire etc.. )
> >
> > Can please you point me to a place where this is done ? So that i can
> hack
> > the code for the time being for my self and later provide a patch if devs
> > are ok with my above idea.
> >
> > thanks,
> > Charith
> >
> >
> >
> >
> >
> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> No, the namespace repairing performed by the serialize and
> >> serializeAndConsume methods is not configurable.
> >>
> >> What is the use case for preserving a redundant namespace declaration
> >> on a SOAP header?
> >>
> >> Andreas
> >>
> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
> >> <ch...@gmail.com> wrote:
> >> > Hi devs ,
> >> >
> >> > When we serialize a OMElement axiom will omit redundant namesspace
> >> > declarations by default. Is it possible to disable this behavior ?
> >> > In my case i want to keep the redundant namesspace declarations in
> SOAP
> >> > headers.
> >> >
> >> >
> >> > thanks,
> >> > Charith
> >> >
> >> > --
> >> > Charith Dhanushka Wickramarachchi
> >> > http://charithwiki.blogspot.com/
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: dev-help@ws.apache.org
> >>
> >
> >
> >
> > --
> > Charith Dhanushka Wickramarachchi
> > http://charithwiki.blogspot.com/
> >
> >
>
> ---------------------------------------------------------------------
> 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/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sat, Nov 19, 2011 at 8:58 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Assuming that the namespace in question is not the SOAP envelope
> namespace, instead of hacking Axiom, wouldn't it be easier to remove
> the namespace declaration from the SOAP envelope (so that it will be
> serialized in the SOAP header block)?
>
How to do this?
In other words it is like this,
The following code gives an xml like this,
OMFactory omFactory = OMAbstractFactory.getOMFactory();
OMElement parentElement = omFactory.createOMElement(new QName("
http://test.com/parent", "parent"));
OMElement childElement = omFactory.createOMElement(new QName("
http://test.com/child","child"));
childElement.setText("child");
parentElement.addChild(childElement);
System.out.println("OMElement ==> " + parentElement.toString());
xml --> <axis2ns1:parent
xmlns:axis2ns1="http://test.com/parent"><axis2ns2:child
xmlns:axis2ns2="http://test.com/child
">child</axis2ns2:child></axis2ns1:parent>
if I change the code like this,
OMFactory omFactory = OMAbstractFactory.getOMFactory();
OMElement parentElement = omFactory.createOMElement(new QName("
http://test.com/parent", "parent"));
OMElement childElement = omFactory.createOMElement(new QName("
http://test.com/child","child"));
childElement.setText("child");
parentElement.addChild(childElement);
*parentElement.declareNamespace("http://test.com/child",
"axis2ns2");*
System.out.println("OMElement ==> " + parentElement.toString());
<axis2ns1:parent xmlns:axis2ns1="http://test.com/parent" xmlns:axis2ns2="
http://test.com/child
"><axis2ns2:child>child</axis2ns2:child></axis2ns1:parent>
How can I get the former serialization format by changing the OMElement at
the latter method. If possible this may solve the charithas' problem.
thanks,
Amila.
>
> Andreas
>
> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
> <ch...@gmail.com> wrote:
> > Hi Andreas,
> >
> > Issue was this causes an Error in a 3rd party web-service engine when
> > processing some soap headers.
> >
> > Scenario is this. Synapse get a soap request which contains some
> redundant
> > namespace declarations at header level which are internally used inside
> the
> > headers. So when synapse forward them to the BE service they get
> omitted as
> > they are defined at SOAP Envelope level.
> >
> > BE services header processor incorrectly assumes that headers are self
> > contained so this causes an error.
> >
> > I was wondering it may make scene to make it configurable as if we think
> > of synapse point of view omitting redundant namespaces may not be a good
> > idea sometimes. Specially integrating with legacies like this. WDYT ? (
> I do
> > agree that this in pure AXIOM point of view its the correct thing to do
> as
> > it will reduce the data content that is written to the wire etc.. )
> >
> > Can please you point me to a place where this is done ? So that i can
> hack
> > the code for the time being for my self and later provide a patch if devs
> > are ok with my above idea.
> >
> > thanks,
> > Charith
> >
> >
> >
> >
> >
> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> No, the namespace repairing performed by the serialize and
> >> serializeAndConsume methods is not configurable.
> >>
> >> What is the use case for preserving a redundant namespace declaration
> >> on a SOAP header?
> >>
> >> Andreas
> >>
> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
> >> <ch...@gmail.com> wrote:
> >> > Hi devs ,
> >> >
> >> > When we serialize a OMElement axiom will omit redundant namesspace
> >> > declarations by default. Is it possible to disable this behavior ?
> >> > In my case i want to keep the redundant namesspace declarations in
> SOAP
> >> > headers.
> >> >
> >> >
> >> > thanks,
> >> > Charith
> >> >
> >> > --
> >> > Charith Dhanushka Wickramarachchi
> >> > http://charithwiki.blogspot.com/
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: dev-help@ws.apache.org
> >>
> >
> >
> >
> > --
> > Charith Dhanushka Wickramarachchi
> > http://charithwiki.blogspot.com/
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Charith Wickramarachchi <ch...@gmail.com>.
On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen <andreas.veithen@gmail.com
> wrote:
> Assuming that the namespace in question is not the SOAP envelope
> namespace, instead of hacking Axiom, wouldn't it be easier to remove
> the namespace declaration from the SOAP envelope (so that it will be
> serialized in the SOAP header block)?
>
Hi ,
Thanks for the tip. I'll try that.
regards,
Charith
>
> Andreas
>
> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
> <ch...@gmail.com> wrote:
> > Hi Andreas,
> >
> > Issue was this causes an Error in a 3rd party web-service engine when
> > processing some soap headers.
> >
> > Scenario is this. Synapse get a soap request which contains some
> redundant
> > namespace declarations at header level which are internally used inside
> the
> > headers. So when synapse forward them to the BE service they get
> omitted as
> > they are defined at SOAP Envelope level.
> >
> > BE services header processor incorrectly assumes that headers are self
> > contained so this causes an error.
> >
> > I was wondering it may make scene to make it configurable as if we think
> > of synapse point of view omitting redundant namespaces may not be a good
> > idea sometimes. Specially integrating with legacies like this. WDYT ? (
> I do
> > agree that this in pure AXIOM point of view its the correct thing to do
> as
> > it will reduce the data content that is written to the wire etc.. )
> >
> > Can please you point me to a place where this is done ? So that i can
> hack
> > the code for the time being for my self and later provide a patch if devs
> > are ok with my above idea.
> >
> > thanks,
> > Charith
> >
> >
> >
> >
> >
> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> No, the namespace repairing performed by the serialize and
> >> serializeAndConsume methods is not configurable.
> >>
> >> What is the use case for preserving a redundant namespace declaration
> >> on a SOAP header?
> >>
> >> Andreas
> >>
> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
> >> <ch...@gmail.com> wrote:
> >> > Hi devs ,
> >> >
> >> > When we serialize a OMElement axiom will omit redundant namesspace
> >> > declarations by default. Is it possible to disable this behavior ?
> >> > In my case i want to keep the redundant namesspace declarations in
> SOAP
> >> > headers.
> >> >
> >> >
> >> > thanks,
> >> > Charith
> >> >
> >> > --
> >> > Charith Dhanushka Wickramarachchi
> >> > http://charithwiki.blogspot.com/
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: dev-help@ws.apache.org
> >>
> >
> >
> >
> > --
> > Charith Dhanushka Wickramarachchi
> > http://charithwiki.blogspot.com/
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
Assuming that the namespace in question is not the SOAP envelope
namespace, instead of hacking Axiom, wouldn't it be easier to remove
the namespace declaration from the SOAP envelope (so that it will be
serialized in the SOAP header block)?
Andreas
On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
<ch...@gmail.com> wrote:
> Hi Andreas,
>
> Issue was this causes an Error in a 3rd party web-service engine when
> processing some soap headers.
>
> Scenario is this. Synapse get a soap request which contains some redundant
> namespace declarations at header level which are internally used inside the
> headers. So when synapse forward them to the BE service they get omitted as
> they are defined at SOAP Envelope level.
>
> BE services header processor incorrectly assumes that headers are self
> contained so this causes an error.
>
> I was wondering it may make scene to make it configurable as if we think
> of synapse point of view omitting redundant namespaces may not be a good
> idea sometimes. Specially integrating with legacies like this. WDYT ? ( I do
> agree that this in pure AXIOM point of view its the correct thing to do as
> it will reduce the data content that is written to the wire etc.. )
>
> Can please you point me to a place where this is done ? So that i can hack
> the code for the time being for my self and later provide a patch if devs
> are ok with my above idea.
>
> thanks,
> Charith
>
>
>
>
>
> On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> No, the namespace repairing performed by the serialize and
>> serializeAndConsume methods is not configurable.
>>
>> What is the use case for preserving a redundant namespace declaration
>> on a SOAP header?
>>
>> Andreas
>>
>> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>> <ch...@gmail.com> wrote:
>> > Hi devs ,
>> >
>> > When we serialize a OMElement axiom will omit redundant namesspace
>> > declarations by default. Is it possible to disable this behavior ?
>> > In my case i want to keep the redundant namesspace declarations in SOAP
>> > headers.
>> >
>> >
>> > thanks,
>> > Charith
>> >
>> > --
>> > Charith Dhanushka Wickramarachchi
>> > http://charithwiki.blogspot.com/
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: dev-help@ws.apache.org
>>
>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Redundant names space removal when Serializing - AXIOM
Posted by Charith Wickramarachchi <ch...@gmail.com>.
Hi Andreas,
Issue was this causes an Error in a 3rd party web-service engine when
processing some soap headers.
Scenario is this. Synapse get a soap request which contains some redundant
namespace declarations at header level which are internally used inside the
headers. So when synapse forward them to the BE service they get omitted
as they are defined at SOAP Envelope level.
BE services header processor incorrectly assumes that headers are self
contained so this causes an error.
I was wondering it may make scene to make it configurable as if we think
of synapse point of view omitting redundant namespaces may not be a good
idea sometimes. Specially integrating with legacies like this. WDYT ? ( I
do agree that this in pure AXIOM point of view its the correct thing to do
as it will reduce the data content that is written to the wire etc.. )
Can please you point me to a place where this is done ? So that i can hack
the code for the time being for my self and later provide a patch if devs
are ok with my above idea.
thanks,
Charith
On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
<an...@gmail.com>wrote:
> No, the namespace repairing performed by the serialize and
> serializeAndConsume methods is not configurable.
>
> What is the use case for preserving a redundant namespace declaration
> on a SOAP header?
>
> Andreas
>
> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
> <ch...@gmail.com> wrote:
> > Hi devs ,
> >
> > When we serialize a OMElement axiom will omit redundant namesspace
> > declarations by default. Is it possible to disable this behavior ?
> > In my case i want to keep the redundant namesspace declarations in SOAP
> > headers.
> >
> >
> > thanks,
> > Charith
> >
> > --
> > Charith Dhanushka Wickramarachchi
> > http://charithwiki.blogspot.com/
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Redundant names space removal when Serializing - AXIOM
Posted by Andreas Veithen <an...@gmail.com>.
No, the namespace repairing performed by the serialize and
serializeAndConsume methods is not configurable.
What is the use case for preserving a redundant namespace declaration
on a SOAP header?
Andreas
On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
<ch...@gmail.com> wrote:
> Hi devs ,
>
> When we serialize a OMElement axiom will omit redundant namesspace
> declarations by default. Is it possible to disable this behavior ?
> In my case i want to keep the redundant namesspace declarations in SOAP
> headers.
>
>
> thanks,
> Charith
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org