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