potential entityID bug in IdP 3.2.1

[Brent Putman]

On 9/28/16 10:59 AM, Liam Hoekenga wrote:
> We recently had a problem where one of our SPs entityID's contained
> trailing spaces, but the metadata we had on the IdP did not.  So we
> got a request that looked like...
>     <saml:Issuer
> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://service.example.umich.edu/
>  </saml:Issuer>

>
> but our response was for "https://service.example.umich.edu/". 
> Unsurprisingly, their SP did not like receiving a response for the
> wrong entityID, and we had a merry little POST fest.

At first I thought you were going to say it didn't work ... but you're
saying it did "work" in that the IdP did successfully issue a
response.  And the SP couldn't match it to its own entityID b/c its own
in-process storage of its own entityID contained a trailing space.

I'm jumping ahead, but that sounds like an SP bug to me, not an IdP
one.  The SP deployer obviously shouldn't have put the trailing space,
but I think the SP should be normalizing it (and probably most all
config values) to remove leading and trailing whitespace.  This isn't a
Shib SP, is it?  That would be a little surprising.


>
> Shouldn't the IdP have denied the entityID with the trailing spaces? 
> We didn't have metadata that matched that entityID.
>

Scott can weigh in if he thinks I'm wrong, but I think it worked as
expected.  Leading and trailing whitespace inside an XML element value
is usually not considered semantically significant, and it is stripped
out when evaluating it.

Imagine this similar perfectly valid pretty-printed XML snippet:

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
      https://service.example.umich.edu/
</saml:Issuer>


Would you expect that the embedded newlines (and spaces) are
syntactically part of the entityID?  I wouldn't.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160928/598329c8/attachment.html>