Responder/AuthnFailed when missing metadata?

[Peter Schober]

I was shown an exception thrown by SSP (as a SAML SP) reporting a
"Responder/AuthnFailed" error (backtrace below) but the IDP admin
discovered that the entityID of the IDP had been changed (by mistake)
and once it was set back to what the SP already had metadata for
everything worked fine.

My question is whether this description of events matches the
exception included below. Obviously Responder/AuthnFailed (when the
IDP actually put a Status of Success into its SAML Assertion) would be
a strange way for the SP to say "I don't know this IDP".

> Unhandled exception
> An unhandled exception was thrown.
>
> tracking number: ...........
>
> Debug information
>
> The debug information below may be of interest to the administrator /
> help desk:
>
> SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
>
> Backtrace:
> 1 www/_include.php:17 (SimpleSAML_exception_handler)
> 0 [builtin] (N/A)
> Caused by: SimpleSAML\Module\saml\Error: Responder/AuthnFailed:
> Authentication failed. Error id
> [urn:uuid:a535420a-d4b1-4266-b724-a28d8054a025]
> Backtrace:
> 4 modules/saml/lib/Message.php:484
> (SimpleSAML\Module\saml\Message::getResponseError)
> 3 modules/saml/lib/Message.php:616
> (SimpleSAML\Module\saml\Message::processResponse)
> 2 modules/saml/www/sp/saml2-acs.php:141 (require)
> 1 lib/SimpleSAML/Module.php:260 (SimpleSAML\Module::process)
> 0 www/module.php:10 (N/A)

Not being the operator of the SP (nor of the IDP, for that matter) I
can't share SSP version details myself but I can ask the SP operator,
if needed.

Thanks,
-peter

[Tim van Dijen]

Hi Peter,

The only question I have is;  is my assumption correct that this happens in an IDP-first flow?  Because I would have expected the IDP to have refused an AuthnRequest addressed to another entityID..

- Tim

Op maandag 6 september 2021 om 14:32:18 UTC+2 schreef Peter Schober:

[Peter Schober]

* Tim van Dijen <tvd...@gmail.com> [2021-09-06 14:35]:

> The only question I have is; is my assumption correct that this
> happens in an IDP-first flow? Because I would have expected the IDP
> to have refused an AuthnRequest addressed to another entityID..

That's a bit of a red herring, I think:

It's SP initiated, but with unusual deployment specifics at play:
The IDP is a (supposedly mostly identical) *test* instance of the real
IDP and the IDP operator has used his local workstation's hosts file
to point his web browser to the test IDP instance for the prod IDP's
host name (instead of consulting the DNS which points to the prod
IDP's IP address).

As long as your test IDP has identical entityID and key material as
the prod IDP that trick allows you to do end-to-end tests with
arbitrary SPs. The mistake here was to give the test IDP its own
entityID, differing from the prod IDP the SP had metadata about.

So I guess for the sake of the argument it could be said to be IDP-initiated.

Best,
-peter

[Peter Schober]

* Tim van Dijen <tvd...@gmail.com> [2021-09-06 14:35]:

> The only question I have is; is my assumption correct that this
> happens in an IDP-first flow? Because I would have expected the IDP
> to have refused an AuthnRequest addressed to another entityID..

I think you're on the right track here but I also think this can
(only?) be explained in SP-initated SSO (not IDP-initiated) assuming
SSP tracks IDs and entityIDs from AuthnRequests and Responses?

If SSP as SP first sent an AuthnRequest to the IDP (correct entityID)
and then got back that same ID as Response/@InResponseTo in a response
coming from a different Response/Issuer (incorrect entityID set on the
IDP clone), would that explain the error?
(If it was IDP-initiated from an unkown IDP there'd be no mismatch and
I'd expect a different error right away.)

-peter

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2021-09-06 14:32]:

> I was shown an exception thrown by SSP (as a SAML SP) reporting a
> "Responder/AuthnFailed" error (backtrace below) but the IDP admin
> discovered that the entityID of the IDP had been changed (by mistake)
> and once it was set back to what the SP already had metadata for
> everything worked fine.

Turns out there was a SAML proxy (of the SaToSa implementation) in
between the IDP and the SimpleSAMLphp SP and that proxy did issue
exactly the SAML error SSP merely reported.

So SimpleSAMLphp is at no fault here.

Sorry for barking up the wrong tree and thanks to Tim for getting us
to look closer.

-peter