Add InResponseTo validation support

[fast-reflexes]

Describe the bug
The InResponseTo field is not validated and the repsonse is not rejected when this does not correspond to a sent request.

To Reproduce

1. Set up SAML2 login and run your server locally which redirects to an IDP which will then redirect to an actual deployed SAML2 authentication endpoint.
2. Set the host of your deployed app to 127.0.0.1 in /etc/hosts
3. Ping the host and verify that localhost responds
4. Start the local app and try to log in, you will be directed to your IDP which will redirect back to the authentication endpoint which will not exist on your local machine, thereby resulting in a not found error.
5. Copy the unresponded request as cURL from the console and paste it in a document.
6. Add flags .L and -i and remove cookies headers to be on the safe side.
7. Remove the entry in /etc/hosts and verify that the actual deployed application responds on ping.
8. Run the command with cURL and verify that the deployed application authentication endpoint accepts the cURL command which is a response to a request NOT initiated by the deployed application but by the local application.

Expected behavior
If the request contains a InResponseTo which is incorrect, it should be rejected.

Sample

A link to a GitHub repository with a minimal, reproducible sample.

Reports that include a sample will take priority over reports that do not.
At times, we may require a sample, so it is good to try and include a sample up front.

[jzheaux]

@fast-reflexes, you are correct - this is because the AuthNRequest is not saved anywhere after the relying party generates and sends it to the asserting party.

I've created a ticket to add that support - #9185 - where your contribution would be most welcome.

Once that is complete, we can take a closer look at this ticket to see how to best validate InResponseTo. In the meantime, would you mind if I changed this ticket to an enhancement and reworded it to Add InResponseTo validation support?

[fast-reflexes]

@jzheaux Thanks for answering! No, go ahead and reword it!

[jzheaux]

@fast-reflexes Now that Saml2AuthenticationRequestRepository is in place, I think we have what's needed to proceed with this ticket.

As I see it, there are two things needed:

• Add an id attribute to AbstractSaml2AuthenticationRequest and populate it in OpenSamlAuthenticationRequestResolver
• Add a validation step in OpenSaml4AuthenticationProvider that compares Response#inResponseTo to Saml2AuthenticationToken#getAuthenticationRequest#getId if both are set

Are you able to provide a PR along those lines? If not, I believe I have some time to do it.