invalid assertion from Shibboleth IdP 2.3.8

[Kevin Hansen]

Cantor, Scott wrote:
> On 7/20/12 7:15 PM, "Kevin Hansen"<kevinh at instructure.com>  wrote:
>
>> I have captured and attached an assertion from the IdP that says it is
>> canonicalized using xml-exc-c14n,  "Exclusive Canonical XML 1.0", and
>> when Canvas tries to validate the assertion after Canonicalizing it this
>> way according to that specification it fails.
>> But, when we force Canvas to use Canonical XML 1.0, xml-c14n, it works.
>
> Actually you captured an unsigned response containing an encrypted
> assertion, so there's no way for anybody to test the claim unless they had
> your key.
Ah, true.  My mistake.  I have attached a copy of the assertion itself, 
unencrypted.
>
> I don't see how it's possible for there to be a bug unless we included a
> patch release of xmlsec in 2.3.8, since none of the code would have
> changed otherwise. Since nothing below shib-common changed in the 2.3.8
> release, I don't see much chance that anything would have changed between
> that version and versions that have been out for a good while and are
> known to work.
>
> We have the advantage that we have to interoperate signatures across two
> completely disparate code bases, so usually we know if it works or not
> unless it's an edge case that's broken in multiple places.
I agree.  We just want to eliminate this as a possibility.
>> This tells me one of two things.  Either the Shibboleth assertion is
>> canonicalized one way (xml-c14n) and reporting another (xml-exc-c14n) or
>> the xmlsec library behind the ruby module has a problem.  Because we
>> think we only have problems with Shibboleth assertions
>> from this version, we suspect the former but that is why we're posting
>> to this list.
>
> I'll be surprised, unless we can locate a regression.
>
>> Is anyone aware of this type of problem?  If this questions is more
>> appropriately posted somewhere else, let me know.
>
> Well, you're claiming a bug, so the thing to do is attach an actual
> signature sample to a bug report, and if it can be determined to a
> reasonable degree that the Java code is correct, it will get marked as
> invalid.
I'm new to this community but I assume this forum is not the place to do 
this.  Can you point me in the right direction?
> For myself I can usually eyeball the XML and guess as to where there might
> be a source of trouble, no matter who is wrong.
I can too, but this case has me stumped.  I've attached an assertion but 
it sounds like I need to look at actually filing a bug.  I'll do that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120720/5fb63d98/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_assertion.xml
Type: text/xml
Size: 5017 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20120720/5fb63d98/attachment.xml