Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sumeetpri opened this issue Dec 8, 2023 · 10 comments
Assignees
Labels
for: stackoverflow A question that's better suited to stackoverflow.com

Comments

@sumeetpri
Copy link

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?

@sumeetpri sumeetpri added status: waiting-for-triage An issue we've not yet triaged type: bug A general bug labels Dec 8, 2023
@jzheaux
Copy link
Contributor

jzheaux commented Dec 11, 2023

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.

@jzheaux jzheaux closed this as completed Dec 11, 2023
@jzheaux jzheaux self-assigned this Dec 11, 2023
@jzheaux jzheaux added for: stackoverflow A question that's better suited to stackoverflow.com and removed status: waiting-for-triage An issue we've not yet triaged type: bug A general bug labels Dec 11, 2023
@sumeetpri
Copy link
Author

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

@darrenpm
Copy link

darrenpm commented Dec 18, 2023

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
Copy link
Contributor

jzheaux commented Dec 18, 2023

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
Copy link
Author

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

@sumeetpri
Copy link
Author

@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
Copy link
Author

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 .

@sumeetpri
Copy link
Author

sumeetpri commented Jan 23, 2024

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

@jzheaux
Copy link
Contributor

jzheaux commented Jan 18, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: stackoverflow A question that's better suited to stackoverflow.com
Projects
None yet
Development

No branches or pull requests

3 participants