debugging xmltooling::IOException...Error reading request body from browser (2746)

[Les LaCroix]

Good afternoon,

I'm an IdP operator trying to get SSO going with a vendor, and I am hoping
someone can suggest some other things for me to check.  I apologize in
advance for the length of the note.

The vendor is Medicat.  Medicat is a member of InCommon, and according to
the metadata, it looks like they have a couple dozen institutions they have
already set up.  They say we are the only ones having this problem.  The
references to us in their metadata looks to be set up the same as their
references to another school.  (Their SP entityID is "
https://sso.medicatconnect.com/shibboleth" and our IdP entityID
is "urn:mace:incommon:carleton.edu", for anyone wanting to look at the
metadata.)

I'm using Chrome with the developer tools and SAML Chrome Panel 1.8.9 in
particular to watch the flow through the browser.

When I go to their institution-specific URL, I am bounced to the InCommon
WAYF.  After selecting our institution, I get bounced back to the vendor
login URL with our entityID.  (I can't think of any other SP we use that
uses the InCommon WAYF, but if it successfully determines our IdP entityID,
I assume that this step is working completely.)

Next I come back from the vendor URL with a redirect to our IdP's
HTTP-Redirect target and an AuthnRequest.  The AssertionConsumerServiceURL
in the request matches the HTTP-POST binding in their metadata, the
ProtocolBinding is HTTP-POST, the destination matches our IdPs's
HTTP-Redirect target, and the issuer is their entityID.  This matches an
AuthnRequest from a working SP (one that does not use the InCommon WAYF).

(During setup, the vendor kept asking me for our SSO login and logout URLs,
and I reminded them that it was in the InCommon metadata.  They asked me to
verify some of the values, which I did, but I think they are using
Shibboleth SP so I don't know why they wouldn't just consume the data
straight from the InCommon metadata.  Feels like an opportunity to
introduce trouble.)

The next thing is a POST to their ACS URL with a signed, encrypted
assertion.  The server immediately comes back with:

xmltooling::IOException at (
https://carleton.medicatconnect.com/Shibboleth.sso/SAML2/POST)

Error reading request body from browser (2746).


So it's not a network timeout or anything like that.  I turned up logging
for org.opensaml.saml.saml2.encryption.Encrypter, and the assertion before
encryption has all of the attributes and values I expect.

Besides their InCommon metadata, the only reference to them in our IdP
configuration is to release an attribute that corresponds to our Student ID
so that they can match against the nightly student import.  That's the only
attribute they asked about, so I expect they aren't using any of the
attributes in the default bundle we release to InCommon SPs.

They asked me to verify their XML stanza for the student ID attribute:

<Attribute name="urn:oid:1.3.6.1.4.1.13755.1.4" id="colleagueID"/>


​Our asserted attribute has the same name, but the id above (colleagueID)
does not match the FriendlyName we assert (carlColleagueID).  That
shouldn't matter, right?  I've asked them to change their attribute
definition to match anyway.

Thanks for reading all this way; any pointers would be appreciated.  I
understand that the vendor has reverted to non-SSO for us, so for the
moment I can't dig any deeper, but I'm hoping we can resume troubleshooting
soon.

Best, -Les

------------------------------
Les LaCroix '79 | Strategic Technologist
Carleton College | 1 N. College St. | MS 3-ITS | Northfield, MN 55057
507.222.5455 | free/busy
<https://calendar.google.com/calendar/embed?src=llacroix%40carleton.edu&ctz=America/Chicago>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180313/ec1a9a13/attachment.html>