<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></head><body><div>> First make sure you find the SAML Reponse from the IDP in your SP's web server logs and make sure it's being HTTP-POST'ed to the correct ACS URL of your SP. If necessary trace the Reponse in the web browser using e.g. SAML-tracer.<br /><br />Thanks for pointing me in the right direction. I misunderstood how Shibboleth works. The POSTs were going to the Shibboleth "protected" app directory which I thought was correct, instead of Shibboleth's ACS URL.<br /><br /><br /><br />* Derek Ricciardi via users <users@shibboleth.net> [2021-10-28 20:11]:<br />> I'm having some trouble configuring my Shibboleth SP for use with IdP initiated SSO. This is the IdP's metadata:<br />><br />> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" <br />> ID="bpjyTajR3wad3ssQLvH9t51OE8_" cacheDuration="PT1440M" <br />> entityID="pfd.digitalinsight.com"><br /><br />JFYI, the entityID is invalid (not of type anyURI because it's not a<br />URL) but that doesn't stop things from working.<br /><br />> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1: </md:NameIDFormat><br /><br />That's also invalid (incomplete nameid format URI).<br /><br />> You can see it has no SingleSignOnService node so it fails validation. <br />> I've added a dummy node and loaded the metadata locally, but <br />> Shibboleth tries to use that dummy node to log on, rather than the <br />> incoming session from the IdP.<br /><br />With proprietary SSO requests (instead of SAML-standard ones) I guess there's no need for SSO endpoints in IDP metadata but the SAML 2.0 Metadata schema requires those.<br /><br />The SP should process the SAML Reponse as usually, though, and not issue an authn request to the IDP. So something's wrong.<br /><br />> I also believe I should be using encryption, which their metadata <br />> makes no mention of...<br /><br />As you can see the IDP did encrypt the Assertion in the SAML Reponse (which I personally find quite surprising, given the IDP provided you with XSD schema-invalid SAML metadata), so that's fine.<br />(The Reponse is also signed and the IDP metadata contains the cert to hopefully match the key that signed the Reponse.)<br /><br />> Below is an example SAML request from the IdP:<br /><br />Nit: Reponse (there's SAML Request with IDP-initiated).<br /><br />> I've configured Shibboleth with the correct signing and encryption <br />> certificates<br /><br />What exactly did you do there? Other than having (valid) metadata for the IDP there should be nothing to configure for a/this IDP in your SP deployment.<br /><br />> and I don't receive any errors anywhere that I can see. But rather than logon attempts in the transaction.log this is all I get:<br />><br />> 2021-10-28 <br />> 17:42:19|Shibboleth-TRANSACTION.AuthnRequest|||pfd.digitalinsight.com|<br />> |||||urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST||||||<br /><br />You said yourself that the SP issues an authentication request to the IDP's SSO endpoint URL, i.e., the fake one you added to make the IDP's metadata schema-valid.<br />So that's probably from that request (only you can know that by matching timestamps with other things happening).<br /><br />> Any ideas what my configuration should look like for this IdP?<br />> Or is the problem with their metadata?<br /><br />Probably neither.<br /><br />First make sure you find the SAML Reponse from the IDP in your SP's web server logs and make sure it's being HTTP-POST'ed to the correct ACS URL of your SP. If necessary trace the Reponse in the web browser using e.g. SAML-tracer.<br /><br />If it was actually POSTed to the correct endpoint (which I find highly<br />unlikely) then the SP would have something in its shibd.log.<br />So that's where you'd look next.<br /><br />-peter<br /><br /><br /></div><div dir="ltr" style="mso-line-height-rule:exactly;-webkit-text-size-adjust:100%;direction:ltr;"><table cellpadding="0" cellspacing="0" border="0" style="width:100%;"><tr style="font-size:0;"><td align="left" style="vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="font-size:0;line-height:normal;"><tr style="font-size:0;"><td align="left" style="padding:0 10px 0 0;vertical-align:top;"><img src="cid:image337408.png@69FA731B.558720E5" height="64" border="0" alt="" style="height:64px;min-height:64px;max-height:64px;font-size:0;" /></td><td align="left" style="padding:10px 0 10px 10px;vertical-align:middle;"><table cellpadding="0" cellspacing="0" border="0" style="width:100%;font-size:0;"><tr style="font-size:24px;color:#0033A0;font-style:normal;font-weight:700;white-space:nowrap;"><td align="left" style="vertical-align:top;font-family:Tahoma;">Derek Ricciardi<span style="font-family:remialcxesans;font-size:1px;color:#FFFFFF;line-height:1px;"></span></td></tr><tr style="font-size:0;"><td align="left" style="vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="font-size:0;color:#5B6770;font-style:normal;font-weight:700;white-space:nowrap;"><tr style="font-size:20px;"><td align="left" style="vertical-align:top;font-family:Calibri;">Software Development Architect</td></tr></table></td></tr><tr style="font-size:0;"><td align="left" style="vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="font-size:0;color:#5B6770;font-style:normal;font-weight:700;white-space:nowrap;"><tr style="font-size:14.67px;"><td align="left" style="padding:11px 0 0;vertical-align:top;font-family:Calibri;">Mid‑Hudson Valley Federal Credit Union</td></tr></table></td></tr><tr style="font-size:0;"><td align="left" style="vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="font-size:0;color:#5B6770;font-style:normal;font-weight:400;white-space:nowrap;"><tr style="font-size:14.67px;"><td align="left" style="vertical-align:top;font-family:Calibri,Arial,sans-serif;">1099 Morton Blvd</td><td align="left" style="vertical-align:top;font-family:Calibri,Arial,sans-serif;">, </td><td align="left" style="vertical-align:top;font-family:Calibri,Arial,sans-serif;">Kingston</td><td align="left" style="vertical-align:top;font-family:Calibri,Arial,sans-serif;">, </td><td align="left" style="vertical-align:top;font-family:Calibri,Arial,sans-serif;">NY</td><td align="left" style="vertical-align:top;font-family:Calibri,Arial,sans-serif;"> 12401</td></tr></table></td></tr><tr style="font-size:0;"><td align="left" style="vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="font-size:0;color:#5B6770;font-style:normal;font-weight:400;white-space:nowrap;"><tr style="font-size:14.67px;"><td align="left" style="vertical-align:top;font-family:Calibri,Arial,sans-serif;"><a href="tel:845-336-4444%20X4909" target="_blank" id="LPlnk689713" style="text-decoration:none;color:#5B6770;"><strong style="font-weight:400;">845-336-4444 X4909</strong></a></td></tr></table></td></tr></table></td></tr></table></td></tr><tr style="font-size:0;"><td align="left" style="vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="font-size:0;color:#808080;font-style:normal;font-weight:400;white-space:nowrap;"><tr style="font-size:12px;"><td align="left" style="padding:11px 0 13px;vertical-align:top;font-family:Calibri,Arial,sans-serif;">This message and any included attachments are confidential, and are intended for the use of the addressee(s). <br />Unauthorized review, forwarding, printing, copying, distributing, or other such uses is strictly prohibited and <br />may be unlawful. If you received this message in error, or believe you are not authorized to receive it, <br />please promptly delete this message and notify the sender of the error.<br /></td></tr></table></td></tr></table></div></body></html>