ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prabath Siriwardena <prab...@wso2.com>
Subject Re: Redundant names space removal when Serializing - AXIOM
Date Thu, 24 Nov 2011 07:39:46 GMT
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

Mime
View raw message