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

[sumeetpri]

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?

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

[sumeetpri]

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

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

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

[sumeetpri]

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

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

[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

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