Implement replay attack mitigation for SAML auth.
Review Request #12476 — Created July 18, 2022 and submitted — Latest diff uploaded
SAML is generally quite secure by design, but if there's a man in the
middle, it is susceptible to replay attacks (within a short limited time
frame). The way this is mitigated is by giving every message and
assertion a unique ID. The service provider can then store these IDs and
make sure that they haven't already been used.
This change implements that. The used IDs are kept in the cache, and
checked before we proceed. While using the cache for this isn't 100%
reliable, given the very short message lifetime, it's good enough for
- Ran unit tests.
- Verified that I could still log in with SAML.
- Crafted a replay and saw that it was successfully blocked.