OpenSAML: Verify Signature after decryption

[Brent Putman]

On 9/8/11 11:50 AM, Nicolas Peifer wrote:
> Hello,
> 
> I decrypted the Extension of an AuthnRequest successfully and now I'm trying 
> to verify the signature (of the whole request). 

Yeah, as Scott already noted, that is the wrong order of operations.  I
believe the SAML core spec discusses this specifically.  For the example
of this particular case, you would first validate the protocol message
signature, and then decrypt its content (e.g. your request extension, a
response's EncryptedAssertion).

Or at least, you can theoretically decrypt the inner thing(s) first,
into a new object tree, but the signature over the thing containing the
encrypted children is always over the encrypted form of the children, so
that's how you have to verify it.  This would work fine in Java
OpenSAML, since the decryption process does *not* replace the decrypted
element with unencrypted one (see below).



> The method 
> decrypter.setRootInNewDocument(true) is called before the decryption begins.
> 

> My understanding of the explainations on the wiki is that the encrypted 
> Extension is now replaced with the decrypted element after the decryption. 

No, absolutely not.  None of our Java decryption options result in the
original Encrypted* thing being replaced in the original source
XMLObject tree by the corresponding decrypted thing.  It always produces
a new XMLObject tree which is unconnected to the original one.  If for
processing pipeline purposes you wanted to replace say a
Response/EncryptedAssertion with the resulting decrypted Assertion (e.g.
so that your code would handle the response the same whether the
Assertion was encrypted or not), you'd have to do that yourself in your
own code.

That rootInNewDocument option is really for the inverse order of
operations of what you describing above: namely a thing (e.g.
EncryptedAssertion) that is encrypted, and where the unencrypted form
was signed before encryption and the signature on it is to be verified
(self-evidently after decryption). This option is necessary due to some
DOM-level requirements that exist in the Apache xmlsec library that we use.