7

I'm implementing a SAML2 Service provider that will be running on a public facing web site. The sign in functionality is publicly available, so anyone can get hold of a AuthnRequest from my site.

When I do receive a response from the Idp, do I have to validate the InResponseTo field to make sure that the response is to a AuthnRequest I've issued or can I ignore it?

I don't understand how it would add any extra security when I'm already validating the signature of the response and have a replay protection by only allowing each assertion id to be used once within the validity time of the assertion (as specified by the condition).

Anders Abel
  • 183
  • 1
  • 6

2 Answers2

1

Yes, according to the SAML spec this must be validated.

I'm not 100% sure of the reason or this. But just thinking out loud. With the contraint on time and sigature, you would still be able to do a replay of the message within the validity time.

Stefan Rasmusson
  • 426
  • 2
  • 11
  • Can you please provide the SAML spec that you mentioned? – Christian H Jun 27 '21 at 23:54
  • In the profiles spec 4.1.4.2 it is very clear that it must match. Also for responses in general in protocols and assertion 3.2.2 "its value MUST match the value of the corresponding request's ID attribute." – Stefan Rasmusson Jun 29 '21 at 08:23
1

It is explained in Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0 section 6.1.3 Message Insertion.

It is primarily a method for blocking fabricated requests inserted into the communication. As a complement to signing and/or SSL. It is not solving a separate security issue but is an in depth defense.

My interpretation is that checking InResponseTo is cheaper than validating the signature and a faster way to ditch invalid messages to avoid DOS attacks.

Albin Sunnanbo
  • 126
  • 3