Skip to Content.
Sympa Menu

mace-opensaml-users - Re: Can't validate Signature of SAML 1.0 Assertion resulting from decrypted EncryptedData

Subject: OpenSAML user discussion

List archive

Re: Can't validate Signature of SAML 1.0 Assertion resulting from decrypted EncryptedData


Chronological Thread 
  • From: "Enrique Rodriguez" <>
  • To:
  • Subject: Re: Can't validate Signature of SAML 1.0 Assertion resulting from decrypted EncryptedData
  • Date: Fri, 6 Apr 2007 19:34:44 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MpzfPxchl9QmKoCB7qQOvRGbAvM8N8c1EiWAqFtt64TVPlCBiHYyHPgre6W62yxOSIDPdKXDUVmels75banQQDAmuBg6FJ4zyQxpJcKX03WEp74Gnee4R2/sfN0Cwh2hUU3WJ1qHjMPXoW3us2kTrszCf4Rd/q6ieXJwrOeRbFc=

On 4/6/07, Brent Putman
<>
wrote:

Scott Cantor wrote:
> When unmarshalling from a file, the library is (possibly incorrectly)
> treating the attribute as an ID, either manually or because it's validating
> with the SAML 1.1 schema set. That results in a valid signature (but
> shouldn't if this is actually SAML 1.0).

Yes, the unmarshaller is still incorrectly setting the IDness even for
MinorVersion = 0. Somewhere I had on my todo list to fix that. I'll
take care of it. But that doesn't explain the problem. I believe it
still should have been (incorrectly) working (i.e. resolving the ID
attribute). My guess is that it would still be broken for SAML 1.1.
I'll try and test.

This is what I'm currently seeing, that it is still broken for SAML
1.1. I just updated my application and tests to use SAML 1.1 tokens
and they still don't validate. The error appears to be identical.

> Decryption is perhaps returning a DOM directly, and there is no way for the
> IDness to be established (even incorrectly) there unless one is validating
> the DOM afterward, or by unmarshalling an XMLObject tree around the DOM,
> which would enable SAML-specific logic to kick in and set IDness that way.

If the Decrypter.decryptData is used(), it unmarshalls an XMLObject
around the DOM DocumentFragment returned by Decrypter.decryptToDOM().
And the unmarshaller there should be (incorrectly) setting the IDness on
the DOM Attribute and therefore the Apache xml-sec IDResolver should be
able to resolve it. So I suspect there's a deeper bug. I suspect
perhaps a DOM node adoption issue - maybe the DOM nodes aren't being
unified into the same Document properly somewhere. I'll have to
investigate some more, this might be a tricky one to debug.

Thanks for the time and effort, guys. I've learned a few things, too.

Enrique



Archive powered by MHonArc 2.6.16.

Top of Page