OpenSAML user discussion

[Brent Putman <>]

Scott Cantor wrote:

I don't know if it's the same problem, but when I decrypt an assertion,
I have to marshall/unmarshall it after decryption before the signature
can be validated (I serialize to a string and read it back using an
unmarshaller).
    

That sounds like a bug. The earlier error relates to the DOM not recognizing
the Assertion ID as an ID attribute, so there may be a bug related to
establishing IDness under some conditions.
  

I think it's not really a bug per se, but is a known issue.  We discussed way back.  When you decrypt, the resulting decrypted XMLObject has a cached DOM tree underneath it.  The Nodes in the tree will be owned by the same Document as the encrypted one.  However, there is no obvious or universally correct place to locate that owned tree, and so by default it isn't rooted in any Document or parent Node.  Sort of an orphaned subtree.

Some cases however require the decrypted Element to exist as part of a Document's tree, e.g. ID resolution.  So the Decrypter has an option to do that.  It's turned off by default, b/c it's expensive relatively speaking and most cases probably don't require.  But signature verification on the decrypted Assertion would. 

See the last few paragraphs of the Javadocs on the java-xmltooling Decrypter (superclass of the SAML Decrypter):

http://www.opensaml.org/docs/xmltooling/1.0.1/apidocs/org/opensaml/xml/encryption/Decrypter.html


So in short, try setting this on the Decrypter

setRootInNewDocument(true)

That should solve that error, and also eliminate the other poster's technique of re-marshalling and re-unmarshalling.  At least I think so.

Let us know how that works out.

--Brent