InResponseTo checking is brittle

[bdewater-thatch]

For added security I'm looking into disallowing IdP initiated flows and requiring SP initiated flows to be used all the time. The current code on master is identical on the v2.x branch:

ruby-saml/lib/onelogin/ruby-saml/response.rb

Lines 626 to 633 in f9263a6

	def validate_in_response_to
	return true unless options.has_key? :matches_request_id
	return true if options[:matches_request_id].nil?
	return true unless options[:matches_request_id] != in_response_to
	error_msg = "The InResponseTo of the Response: #{in_response_to}, does not match the ID of the AuthNRequest sent by the SP: #{options[:matches_request_id]}"
	append_error(error_msg)
	end

This works if you don't specifically care about this, but is odd to work with if you do. You can't use options[:matches_request_id] = session.delete("saml_request_id") (assuming you stored Authrequest#uuid there before) since it may return nil and the above code returns early. Passing in an empty string instead works but feels clunky.

Should there be an explicit security setting like want_request_id (like want_assertions_signed and want_name_id so that a nil value doesn't pass validation?

[bdewater-thatch]

The current implementation also doesn't conform to the specification:

A reference to the identifier of the request to which the response corresponds, if any. If the response is not generated in response to a request, or if the ID attribute value of a request cannot be determined (for example, the request is malformed), then this attribute MUST NOT be present. Otherwise, it MUST be present and its value MUST match the value of the corresponding request's ID attribute.

This could be a thing to change before 2.0 ships.

[pitbulk]

@bdewater-thatch Sorry for the delayed reply.

To avoid replay attacks, the solution is not as simple as rejecting IdP-initiated SAML flows.

Instead, you may store in a database the assertion ids processed and validated, you can set a TTL of X min to those values (where X is the expiration time of the assertion).

Alg:

1. Validate the SAMLResponse.
2. Check that the assertion id does not exist in your database.
3. If it exists, invalidate the SAMLResponse/Assertion; if it does not exist, mark the SAMLResponse/Assertion as valid and register it in the DB.