Skip to Content.
Sympa Menu

mace-opensaml-users - Re: [OpenSAML] Odd decryption/signature interaction

Subject: OpenSAML user discussion

List archive

Re: [OpenSAML] Odd decryption/signature interaction


Chronological Thread 
  • From: Brent Putman <>
  • To:
  • Subject: Re: [OpenSAML] Odd decryption/signature interaction
  • Date: Tue, 28 Sep 2010 19:46:47 -0400



On 9/28/10 6:24 PM, Nick Newman wrote:
> Hi,
>
>
> So, I have configured a SP to use OpenSAML to check SAML tickets
> obtained from Shibboleth.
>

Just to confirm - your SP is written with Java OpenSAML 2.x, not C++? I
have an earlier msg from you on the list that suggests you are working
in Java, just wanted to make sure.


>
> If I configure Shibboleth to now encrypt the Assertion then I can
> decrypt and then validate the signature on that Assertion, but then
> the signature on the Response fails to validate.
>
> That make it look as if decrypting the Assertion has changed the
> Response object. So to check this I checked the signature on the
> Response both before and after decrypting the Assertion, and sure
> enough the first one succeeded and the second failed.
>
> So am I to understand from this that decrypting the Assertion does
> something like replacing the EncryptedAssertion in the Response with
> the "plain" Assertion?



No, it doesn't intend to replace the EncryptedAssertion with the
decrypted Assertion at the level of OpenSAML's SAMLObjects. In other
words, the SAMLObject object graph itself should remain unchanged. What
I suspect might be happening is some side-effect that is happening at
the DOM level. Something about the decryption op is affecting the
cached DOM tree held by the Response, which is what the signature
validation actually operates on (implemented by Apache xmlsec).

One question would be: are you explicitly setting the rootInNewDocument
property of the Decrypter? If not, you might try setting that to true
and see if that changes things. I can't see that it would, but would be
nice to know.

Still sounds like probably a bug, though. It might either be in our
code or the underlying Apache xmlsec. We probably haven't heard about
it until now because, practically speaking, you'd generally always want
to validate the Response protocol message before you even look at the
payload, and once you start processing the payload you'd generally never
go back and re-validate the Response.

If you'd like to open a Jira issue and post some code that reproduces
the problem, I'll take a look.





Archive powered by MHonArc 2.6.16.

Top of Page