Spring Security OpenSaml4AuthenticationProvider should validate Response Status

When the IdP returns an AuthnResponse for a failed authentication flow without any assertions the statusCode is not returned in the Exception. This was already raised in https://github.com/spring-projects/spring-security/issues/8955 and corrected in the now deprecated OpenSamlAuthenticationProvider.

We use a custom AuthenticationFailureHandler in our saml2 configuration and we would like access to the StatusCode and StatusMessage of the Response in case of an Exception. This context is now lost in OpenSaml4AuthenticationProvider because of the code:

    if (response.getAssertions().isEmpty()) {
        throw createAuthenticationException(Saml2ErrorCodes.MALFORMED_RESPONSE_DATA,
       "No assertions found in response.", null);
    }

If for example the IdP returns the following XML:

<samlp:Response Destination="https://connect.test2.surfconext.nl/login/saml2/sso/oidcng"
    ID="CORTOcf0d43b90d6b32d2e667aca916e9d574f2c6e3af"
    InResponseTo="ARQ21e1bc5-552f-4e39-b27b-4ad9d22988dd" IssueInstant="2021-05-04T08:49:52Z"
    Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer>https://engine.test.surfconext.nl/authentication/idp/metadata</saml:Issuer>
    <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext"/>
        <samlp:StatusMessage>The requesting service has indicated that the authenticated user is required to
            have an affiliation Student. Your institution has not provided this affiliation.</samlp:StatusMessage>
    </samlp:Status>
</samlp:Response>

The StatusCode and StatusMessage should be logged and preferably made available in the Exception thrown, so FailureHandlers downstream can handle this.

There is already a hook for setting a custom AssertionValidator in , but no hook for a custom ResponseValidator in OpenSaml4AuthenticationProvider. I would be happy to write a PR, if you can confirm that this is desired behaviour,

Comment From: jzheaux

@oharsta thanks for the report. It looks like this was missed, so let's use this ticket to fix the bug.

Regarding your other request about having the status code in the exception, would you mind filing a separate ticket for that? The reason is the two changes will release at different times.

Comment From: oharsta

@jzheaux Thanks. Could I suggest one very minor change: to correlate the exception to the initial SAML request it would be very helpful for us to have the inResponseTo instead of (or in addition to) the ID of the Response in the error message.