9

Should a SAML federation software accept the same SAML response as long as it is within the allowed SAML token lifetime?

In simpler terms: IDP (identify provider) issues a SAML response, then SP (service provider) accepts/processes it. Can the same unmodified SAML response be then re-used immediately after the first use? Given that the SAML issuance timestamp is within allowed range.

Security-wise it makes sense to restrict a SAML token (response) to only one use, so that even if it is stolen by a "man-in-the-middle" - it cannot be reused. But in order to implement that, the software needs to store some info about the SAML response somewhere: serial number, a hash of the whole thing?

Please provide some links with the explanations on that is possible and/or examples of implementation.

Thank you! Alex.

Alex Kovshovik
  • 4,085
  • 4
  • 35
  • 36

2 Answers2

10

The SAML 2.0 norm provides another way to prevent replay attacks that do not imply storing in database the ID of the assertion.

  • The SP sends a request with an ID="X" and stores this ID in session.
  • The IDP authenticates the user and sends back a Response with an ID="Y" AND a InResponseTo="X" (which is also normally present in the assertion in the SubjectConfirmationData).
  • The SP gets the Response and check that all the InResponseTo values match the one in session. If not, the SP rejects the response.
  • The SP clears the ID in session, thus making replay of the Response impossible. In the ideal case, the SP should clear the ID in session as soon as it receives the response.

This check really complicates the replay attack, as an attacker will also need to have the session cookie of the SP (and even in this case, it's already game over anyway...). It's also good practice to sign the whole response.

Obviously this method is only valid in a SP-initiated scenario.

sk_
  • 2,105
  • 17
  • 31
6

Does it make sense, security-wise? Sure. And in fact you can use the "xs:ID" portion of an assertion to assist you (my company's software does).

From Page 9 of CORE:

The xs:ID simple type is used to declare SAML identifiers for assertions, requests, and responses. Values declared to be of type xs:ID in this specification MUST satisfy the following properties in addition to those imposed by the definition of the xs:ID type itself:

• Any party that assigns an identifier MUST ensure that there is negligible probability that that party or any other party will accidentally assign the same identifier to a different data object.

• Where a data object declares that it has a particular identifier, there MUST be exactly one such declaration.

We snatch that ID from an assertion, and drop it into an array with the not-after time, and then throw it out after that time expires. This way the same assertion can't be replayed.

In other software (especially home-grown stuff), this is entirely managed with the Not-Before and Not-On-Or-After portion of the Audience Restriction. Since some software counts solely on these values, the suggested method is to set this period as short as is reasonable. In the perfect world, everyone is using time servers, and their clock skew isn't more than a couple of seconds. A minute prior, and a minute post issue time should be far more than sufficient. While there isn't as much "security" here, it can be "managed".

Andrew K.
  • 3,240
  • 12
  • 23
  • Thank you Andy. We're indeed relying only on "NotBefore" and "NotAfter" to "expire" SAML assertions. It sounds like "xs:ID" is just another layer of security: to prevent the same assertion from reuse. Makes perfect sense! Thank you! – Alex Kovshovik Mar 16 '14 at 03:02