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 <[email protected]>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 < > [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 > -- Thanks & Regards, Prabath http://blog.facilelogin.com http://RampartFAQ.com
