OpenSAML user discussion

["Taylor, Christopher" <>]

Hi,

 

decrypter.setRootInNewDocument(true) fixed it! Thanks Brent, Scott and Joakim for the suggestions!

 

I’m pretty new to OpenSAML (and SAML in general), but is verifying the signature on a decrypted assertion (or XMLObject in general) really so uncommon? I’d actually run across the documentation Brent mentions below, but didn’t realize it applied to my use case. Maybe adding a constructor which allows specifying this option (and adding the notice to its javadoc) would make it more obvious.

 

Anyway, thanks again!

  --Chris

 

 

--

Christopher Taylor ()

Tel: +49 30 3463 9225

 

Fraunhofer Institute for Open Communication Systems (FOKUS) CC eGovernment and Applications (ELAN)

 

Fraunhofer Institut für Offene Kommunikationssysteme (FOKUS) Kompetenzzentrum eGovernment und Applikationen (ELAN)

 

Kaiserin-Augusta-Allee 31

10589 Berlin

 

Von: Brent Putman [mailto:]
Gesendet: Mittwoch, 19. November 2008 06:44
An:
Betreff: Re: [OpenSAML] error validating signature on SAML2 EncryptedAssertions decrypted with OpenSAML

 

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