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 <[email protected]>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 <[email protected]> > wrote: > > > > Hi Andreas; > > On Wed, Nov 23, 2011 at 2:41 PM, Andreas Veithen < > [email protected]> > > 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 <[email protected]> > >> wrote: > >> > > >> > > >> > On Wed, Nov 23, 2011 at 1:13 AM, Sanjiva Weerawarana > >> > <[email protected]> > >> > 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 > >> >> <[email protected]> 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 > >> >>> <[email protected]> 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 > >> >>> > <[email protected]> > >> >>> > 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 > >> >>> >> <[email protected]> wrote: > >> >>> >> > http://www.w3.org/TR/xml-c14n > >> >>> >> > > >> >>> >> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana > >> >>> >> > <[email protected]> > >> >>> >> > wrote: > >> >>> >> >> > >> >>> >> >> Please look at the C14N spec. > >> >>> >> >> > >> >>> >> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen > >> >>> >> >> <[email protected]> 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 > >> >>> >> >>> <[email protected]> wrote: > >> >>> >> >>> > Thanks for the clear writeup Andreas. > >> >>> >> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen > >> >>> >> >>> > <[email protected]> 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: [email protected] > >> >>> >> >>> For additional commands, e-mail: [email protected] > >> >>> >> >>> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> -- > >> >>> >> >> 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: [email protected] > >> >>> >> For additional commands, e-mail: [email protected] > >> >>> >> > >> >>> > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > 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: [email protected] > >> >>> For additional commands, e-mail: [email protected] > >> >>> > >> >> > >> >> > >> >> > >> >> -- > >> >> 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > > > -- > > Thanks & Regards, > > Prabath > > > > http://blog.facilelogin.com > > http://RampartFAQ.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Thanks & Regards, Prabath http://blog.facilelogin.com http://RampartFAQ.com
