<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
Cantor, Scott wrote:
<blockquote
cite="mid:BA63CEAE152A7742B854C678D949138330A3C35A@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<pre wrap="">On 7/20/12 7:15 PM, "Kevin Hansen" <a class="moz-txt-link-rfc2396E" href="mailto:kevinh@instructure.com"><kevinh@instructure.com></a> wrote:
</pre>
<blockquote type="cite"><pre wrap="">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.
</pre></blockquote>
<pre wrap=""><!---->
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.</pre>
</blockquote>
Ah, true. My mistake. I have attached a copy of the assertion itself,
unencrypted.<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D949138330A3C35A@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
I agree. We just want to eliminate this as a possibility.<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D949138330A3C35A@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">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.
</pre></blockquote>
<pre wrap=""><!---->
I'll be surprised, unless we can locate a regression.
</pre>
<blockquote type="cite"><pre wrap="">Is anyone aware of this type of problem? If this questions is more
appropriately posted somewhere else, let me know.
</pre></blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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?<br>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D949138330A3C35A@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
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.<br>
</body></html>