IdP initiated SSO SP configuration help

Peter Schober peter.schober at
Thu Oct 28 18:54:33 UTC 2021

* Derek Ricciardi via users <users at> [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="">

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

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


More information about the users mailing list