invalid assertion from Shibboleth IdP 2.3.8
Cantor, Scott
cantor.2 at osu.edu
Fri Jul 20 20:03:34 EDT 2012
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.
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.
>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.
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.
-- Scott
More information about the users
mailing list