Hi Chad, The tree does not get walked at all in 1.5.0. The calling code must take care of this and set the appropriate elements on the context. The 1.4.x IdResolver code *does* walk the tree looking for elements with Ids in certain namespaces - this has been removed due to security concerns.
For example, WSS4J walks the tree looking for the appropriate Ids, and throws an error if there are multiple elements matching the same Id. Colm. On Tue, Dec 20, 2011 at 3:37 PM, Chad La Joie <[email protected]> wrote: > That code would be part of the solution. But does the entire tree get > walked or does the IdResolver just stop once it finds a match (which I > thought was what happened). > > > On Tue, Dec 20, 2011 at 10:35, Sean Mullan <[email protected]> wrote: >> On 12/20/2011 10:19 AM, Chad La Joie wrote: >>> >>> On Tue, Dec 20, 2011 at 04:58, Colm O hEigeartaigh<[email protected]> >>> wrote: >>>> >>>> This is already available via the JSR-105 API by setting the >>>> "javax.xml.crypto.dsig.cacheReference" property to true. Apache WSS4J >>>> uses this to build a set of protected element results, that can be >>>> subsequently compared to an XPath expression via WS-SecurityPolicy. >>> >>> >>> Thanks for the pointer. >>> >>>> It is up to the application calling the signature verification code to >>>> ensure that ID's are unique. The 1.5.0 release tightens this >>>> requirement by not searching the document tree for any IDs in "known" >>>> namespaces. The calling code must find the desired elements and >>>> register them on the context/IdResolver for signature validation to >>>> work. >>> >>> >>> I really think the library should support this directly and by >>> default. Given *zero* systems using the library did the right thing >>> in the review done by the researchers, I think it's safe to say this >>> is non-obvious. >>> >>> Let me ask this a different way. What speaks against adding this >>> check in if, via an option, it can be disabled and remove the >>> performance hit that would be caused? >> >> >> This is actually fixed in 1.5, unless I'm misunderstanding the issue. See >> the code for registerElementById() in [1] >> >> public static void registerElementById(Element element, String idValue) { >> Document doc = element.getOwnerDocument(); >> synchronized (docMap) { >> Map<String, WeakReference<Element>> elementMap = docMap.get(doc); >> if (elementMap == null) { >> elementMap = new WeakHashMap<String, >> WeakReference<Element>>(); >> docMap.put(doc, elementMap); >> elementMap.put(idValue, new WeakReference<Element>(element)); >> } else { >> WeakReference<Element> ref = elementMap.get(idValue); >> if (ref != null) { >> if (!ref.get().equals(element)) { >> throw new IllegalArgumentException("ID is already >> registered"); >> } >> } else { >> elementMap.put(idValue, new >> WeakReference<Element>(element)); >> } >> } >> } >> } >> >> Note the lines where it checks if the ID is already registered, and throws >> an IllegalArgumentExc. >> >> --Sean >> >> [1] >> http://svn.apache.org/viewvc/santuario/xml-security-java/tags/1.5.0-RC1/src/main/java/org/apache/xml/security/utils/IdResolver.java?view=markup > > > > -- > Chad La Joie > www.itumi.biz > trusted identities, delivered -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
