Spring Security Configuring SAML2: Bypassing 'InResponseTo' Validation While Retaining Default Settings in OpenSaml4AuthenticationProvider

I have a Java backend application running behind Nginx, and it currently lacks a mechanism to remember cookie sessions. The existing default implementation requires the validation of the 'InResponseTo' attribute if it's present. I want to know if there's a way to disable the 'InResponseTo' validation while still utilizing the default validation provided by OpenSaml4AuthenticationProvider. Notably, SAML2 considers the 'InResponseTo' attribute optional. What is the best method to maintain default validation but bypass 'InResponseTo' through backend configuration settings?

Comment From: jzheaux

Thanks for getting in touch! It feels like this is a question that would be better suited to Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question and I'll be happy to follow up with you there.

Comment From: sumeetpri

@jzheaux It would be great if you share some insight into this as stackoverflow is not very active after chatgpt.

Comment From: darrenpm

I have the same question/request. Unless there's a simple answer using the existing code, I feel like this is a valid enhancement request.

As a workaround/hack for this specific issue, since InResponseTo within the assertion is optional, I've just set it to null using the assertion decrypter:

    @Bean
    public OpenSaml4AuthenticationProvider openSaml4AuthenticationProvider() {
        OpenSaml4AuthenticationProvider provider = new OpenSaml4AuthenticationProvider();

        // Post-filtering of response validation to ignore InResponseTo error
        provider.setResponseValidator(token -> {
            Saml2ResponseValidatorResult result = OpenSaml4AuthenticationProvider
                .createDefaultResponseValidator()
                .convert(token);
            if (!result.hasErrors()) {
                return result;
            }

            // filter out InResponseTo error
            Saml2ResponseValidatorResult newResult = Saml2ResponseValidatorResult.success();
            result.getErrors().forEach(error -> {
                if (!error.getErrorCode().equals(Saml2ErrorCodes.INVALID_IN_RESPONSE_TO)) {
                    newResult.concat(error);
                }
            });

            return newResult;
        });

        // sets the optional InResponseTo assertion value to null to skip validation
        provider.setAssertionElementsDecrypter(token -> {
            if (token.getAssertion().getSubject() != null && token.getAssertion().getSubject().getSubjectConfirmations() != null) {
                token.getAssertion().getSubject().getSubjectConfirmations().forEach(subjectConfirmation -> {
                    if (subjectConfirmation.getSubjectConfirmationData() != null) {
                        subjectConfirmation.getSubjectConfirmationData().setInResponseTo(null);
                    }
                });
            }
        });

        return provider;
    }

That seems to work, but a solution via the assertion validator would be preferable.

Comment From: jzheaux

Happy to help, @sumeetpri. Do you have a StackOverflow post that you can link to here? Then, we can continue this conversation over there.

Comment From: sumeetpri

@jzheaux -My StackOverflow question https://stackoverflow.com/questions/77682671/configuring-saml2-bypassing-inresponseto-validation-while-retaining-default-s

Comment From: sumeetpri

@jzheaux -My StackOverflow question https://stackoverflow.com/questions/77682671/configuring-saml2-bypassing-inresponseto-validation-while-retaining-default-s

@jzheaux Looking for your expert input in stack overflow question .

Comment From: sumeetpri

@jzheaux looking forwarded for your input on https://stackoverflow.com/questions/77682671/configuring-saml2-bypassing-inresponseto-validation-while-retaining-default-s?noredirect=1#comment136958280_77682671

Comment From: sumeetpri

I followed @jzheaux suggestion is stack oveflow , but it does not completely ignores InResponseTo to from validation list because subject confirmation again tries to validate and there is no specific to filter from createAssertionValidato. I think it would be great if there is appropriate flag to disable session cache and do minimal validation how spring extension core used to have .

Comment From: sumeetpri

@jzheaux Whats your thought on explicitly setting setAssertionElementsDecrypter to sets the optional InResponseTo assertion value to null to skip validation as suggested by @darrenpm above ? As alone skkiping via filter is not working as you suggested in stack overflow .

Comment From: jzheaux

I apologize for the delay here, @sumeetpri and others. This is what I read in the spec (see section 3.2.1, emphasis mine):

A reference to the identifier of the request to which the response corresponds, if any. If the response is not associated with a request, or if it is responding to a request that was not identified with an ID attribute, then the InResponseTo attribute MUST NOT be present. If the request was identified with an ID attribute, then the InResponseTo attribute MUST be present in the corresponding response, and its value MUST match the value of the ID attribute in the request.

Because of that, I'm not sure that now it the right time to add a feature to support this.

In the meantime, have you already tried createDefaultAssertionValidatorWithParameters? You should be able to provide a consumer that removes SAML2AssertionValidationParameters.SC_VALID_IN_RESPONSE_TO from the context:

OpenSaml4AuthenticationProvider.createDefaultAssertionValidatorWithParameters((params) -> {
    params.remove(SAML2AssertionValidationParameters.SC_VALID_IN_RESPONSE_TO);
})

I've updated StackOverflow with the same information: https://stackoverflow.com/a/77782442/2243324