IdP initiated SSO SP configuration help

[Derek Ricciardi]

> 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.

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.



* Derek Ricciardi via users <users at shibboleth.net> [2021-10-28 20:11]:
> I'm having some trouble configuring my Shibboleth SP for use with IdP initiated SSO. This is the IdP's metadata:
>
> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" 
> ID="bpjyTajR3wad3ssQLvH9t51OE8_" cacheDuration="PT1440M" 
> entityID="pfd.digitalinsight.com">

JFYI, the entityID is invalid (not of type anyURI because it's not a
URL) but that doesn't stop things from working.

> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1: </md:NameIDFormat>

That's also invalid (incomplete nameid format URI).

> You can see it has no SingleSignOnService node so it fails validation. 
> I've added a dummy node and loaded the metadata locally, but 
> Shibboleth tries to use that dummy node to log on, rather than the 
> incoming session from the IdP.

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.

The SP should process the SAML Reponse as usually, though, and not issue an authn request to the IDP. So something's wrong.

> I also believe I should be using encryption, which their metadata 
> makes no mention of...

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.
(The Reponse is also signed and the IDP metadata contains the cert to hopefully match the key that signed the Reponse.)

> Below is an example SAML request from the IdP:

Nit: Reponse (there's SAML Request with IDP-initiated).

> I've configured Shibboleth with the correct signing and encryption 
> certificates

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.

> 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:
>
> 2021-10-28 
> 17:42:19|Shibboleth-TRANSACTION.AuthnRequest|||pfd.digitalinsight.com|
> |||||urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST||||||

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.
So that's probably from that request (only you can know that by matching timestamps with other things happening).

> Any ideas what my configuration should look like for this IdP?
> Or is the problem with their metadata?

Probably neither.

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.

If it was actually POSTed to the correct endpoint (which I find highly
unlikely) then the SP would have something in its shibd.log.
So that's where you'd look next.

-peter



Derek Ricciardi
Software Development Architect
Mid-Hudson Valley Federal Credit Union
1099 Morton Blvd, Kingston, NY  12401
845-336-4444 X4909
This message and any included attachments are confidential, and are intended for the use of the addressee(s). 
​Unauthorized review, forwarding, printing, copying, distributing, or other such uses is strictly prohibited and 
​may be unlawful. If you received this message in error, or believe you are not authorized to receive it, 
​please promptly delete this message and notify the sender of the error.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20211029/612dba71/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image337408.png
Type: image/png
Size: 9820 bytes
Desc: image337408.png
URL: <http://shibboleth.net/pipermail/users/attachments/20211029/612dba71/attachment.png>