OpenSAML user discussion

[Nick Newman <>]

Hi Brent,

To confirm, it is the Java OpenSAML 2.x I am using, not the C++.  And
yes, I am explicitly setting the rootInNewDocument of the Decrypter to
true.

But now I have to hang my head in shame  :-(

I carefully tried to extract all the metadata and keys and code and
libraries and response XML necessary to send you a nice clean sample,
and when I finally got all the parts together - it worked just fine.

So I assumed I hadn't reproduced some feature of the original problem.
 But when I tried to put the original back to doing the double-check -
it worked fine too!

So although I *know* that I saw this effect (and in fact still have
the evidence of it in my logs) I am totally at a loss to explain why I
cannot reproduce it now.  It's not like there's much to go wrong in
writing three method calls:  check(); decrypt(); check();

I suggest we put it down to my system's weirdness (or its operator's)
and forget it unless it turns up again.

I apologise for taking your time.

Thanks,
Nick

On Tue, Sep 28, 2010 at 5:46 PM, Brent Putman 
<>
 wrote:
>
>
> 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.
>
>
>