Repository navigation
(Obsolete) ExpectedIssuer mismatch exception added again? #2691
Description
In 2018 with commit e543fe5 the behaviour of SSP was changed such that if the expected issuer did not match the one for which an assertion was received, did not throw an exception anymore.
I was suggesting this back then because as far as I know there is nothing in the SAML spec that requires this check and there is IMHO also no good reason why this should be checked. Shibboleth doesn't check this either.
So, I wonder why with with commit 2d9426f this behaviour of throwing an exception was added again. What is the reason behind this?
In our hybrid (Switch edu-ID) federation we have the scenario where users are sent to IdP A (which runs on a host that virtualizes IdPs B, C, D ...) and the returns with an assertion from IdP B to the SP. In case this SP is a newer SSP SP, this then causes an error due to this exception and it's not clear to me what the security or other benefit of this check is to be, provided SSP has metadata for both, IdP A and IdP B anyway.
Activity
tvdijen commentedon Nov 2, 2026
Your question confuses me a bit, because you mention issuer of the assertion, but the code you're pointing at is about the issuer of a response.
lhaemmerle commentedon Nov 3, 2026
Sorry, for the confusion. Yes, in both cases the code deals with the ExpectedIssuer of a response. My question is: Why throwing an error (again) and not just a warning as before?
tvdijen commentedon Nov 3, 2026
I think the short answer is because this is a very unusual use-case and we didn't realize when we did a rewrite of this piece of code.
@ioigoume @thijskh thoughts? would it be an idea to put this behaviour behind a feature-flag? Default to throwing an exception and pass if enabled? (doesn't even have to log a warning in this case)..