XML dig sig error after upgrade to java7u25

Question

I have a Java application for signing XML documents. After upgrading Java to the latest version (Java7u25) it stops working. I get the following error:

javax.xml.crypto.dsig.XMLSignatureException:
javax.xml.crypto.URIReferenceException: 
com.sun.org.apache.xml.internal.security.utils.resolver.ResourceResolverException:
Cannot resolve element with ID ...

Reverting back to java7u21 solves the problem. Is there any change in the XML Dig Sig API that causes this error?

Answer 1

i faced the same issue and also tracked it down to the code snippets mentioned by Cerber. I'm curious whether this is a bug or a change made on purpose.

With the information given in this thread Java XML DOM: how are id Attributes special? i was able to get things back to work again.

In a nutshell the 'ID' attribute has to be of type 'xs:ID' (and not e.g. 'xs:string') for the Dereferencer to find it. Also note that depending on your use of a DocumentBuilderFactory the XML schema must be set.

Answer 2

I had the same probleme with the code :

element.setAttributeNS(null, "Id", elementID);

FIX : specify id

element.setAttributeNS(null, "Id", elementID);
Attr idAttr = element.getAttributeNode("Id");
element.setIdAttributeNode(idAttr, true);

Answer 3

I also found the responses to this question quite helpful, but my solution was a bit different. I'm working with OpenSAML 2.6.0, and assigning a schema to the DocumentBuilderFactory just before parsing the incoming document resolved the ResourceResolverException: Cannot resolve element with ID... exception by properly marking the ID attributes. Here's an example:

InputStream in = new ByteArrayInputStream(assertion.getBytes());       
SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema(new URL("http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd"));
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
factory.setSchema(schema);
Document document = factory.newDocumentBuilder().parse(in);

Answer 4

I am facing the same issue only when ID is set with random UUID [guidForSignature ="_" + UUID.randomUUID().toString();] and when there are concurrent requests triggered at run time(Java 1.8).

I have tried setting the ID attribute like below which didn't help me. However, setting the ID attribute to constant ID value for all the requests resolved the issue.

Element element1= doc.getDocumentElement().setIdAttribute("ID", true);

OR

Element e1 =(Element)doc.getElementsByTagName("Assertion").item(0);
e1.setIdAttribute("ID", true);

Answer 5

Same problem here. Seems to be a bug inside the JVM due to an evolution.

I've traked it down to com.sun.org.apache.xml.internal.security.utils.resolver.implementations.ResolverFragment

In java 7u21 & before :

91: // Element selectedElem = doc.getElementById(id);
92: selectedElem = IdResolver.getElementById(doc, id);

In java 7u25 :

87: selectedElem = doc.getElementById(id);
    //...
93: if (secureValidation) {

secureValidation refers to java 7u25 evolution on XML Sig validation (see changelog) so they must have broken changed something else while working on this evolution.

We've worked around this issue by providing a custom javax.xml.crypto.URIDereferencer to javax.xml.crypto.dom.DOMCryptoContext.setURIDereferencer(URIDereferencer) which is able to resolve node which are not yet in the DOM document tree (fragments in XMLObject).

I'm reporting this to Oracle right now, I'll update the answer with the bug id.

---

EDIT : found this in apache SVN

---

Edit 2 : Thanks to this bug report I've understood that this was an evolution in XML "Id" attributes handling.

Previous versions of java/JSR-105/SANTUARIO used to be very tolerant on "Id" attributes used in document.getElementById(...) but this new version requires an attribute that is identified as ID XML speaking. I mean that naming the attribute "Id" or "ID" is not sufficient anymore, you need to get it marked as ID, eventually by an XSD/DTD schema validation.

Unfortunalty, I'm following a schema that is not valid and therefore not parsable by Java.

If you are in the same situation see my solution below. Otherwise, if you're XML document does have a valid schema, have a look at @sherb solution https://stackoverflow.com/a/17437919/233906

Solution

Fortunately, you can tag an attribute as an ID using methods like Element.setIdAttributeNode(org.w3c.dom.Attr,boolean).

Combining with a little XPath like descendant-or-self::*/@Id to fetch Attr "Id" nodes plus a little Java ((Element)attr.getOwnerElement()).setIdAttributeNode(attr,true) should get you out of trouble.

But be carefull : setIdAttributeXXX() is valid only for the current document & node. If you clone/adopt/import you need to do a setIdAttributeXXX() on the new nodes of each DOM tree

Answer 6

If you have

dsObjectChild.setAttribute("Id", "My-id-value");

Change it to

dsObjectChild.setAttribute("Id", "My-id-value");
dsObjectChild.setIdAttribute("Id", true);

It is working with java 1.7.0_45