It would be nice if Spring Security SAML had out-of-the-box support for <OneTimeUse> elements. With the introduction of OpenSaml5AuthenticationProvider.AssertionValidator, this is much easier to do than before by way of adding something like:
Builder replayCache(Cache cache)
to OpenSaml5AuthenticationProvider.AssertionValidator.Builder.
Internally, the builder could adapt the Spring Cache implementation to an OpenSAML ReplayCache and by virtue of this, construct an OpenSAML OneTimeUseConditionValidator.
Note that ReplayCache includes expiry semantics in its check method, but Spring Cache does not. As such, the adapter will need to account for the TTL in its cache lookup, for example by including the expiry time in the cached element. The key itself can be the assertion ID; we can be more strict about this since applications can quite easily construct a OneTimeUserConditionValidator if they want different behavior.
For passivity reasons, this is strictly an opt-in feature; for applications not using this feature, they remain responsible for validating OneTimeUse elements as they already are today.
Please include unit tests, JavaDoc, and reference documentation.
It would be nice if Spring Security SAML had out-of-the-box support for
<OneTimeUse>elements. With the introduction ofOpenSaml5AuthenticationProvider.AssertionValidator, this is much easier to do than before by way of adding something like:to
OpenSaml5AuthenticationProvider.AssertionValidator.Builder.Internally, the builder could adapt the Spring
Cacheimplementation to an OpenSAMLReplayCacheand by virtue of this, construct an OpenSAMLOneTimeUseConditionValidator.Note that
ReplayCacheincludes expiry semantics in itscheckmethod, but Spring Cache does not. As such, the adapter will need to account for the TTL in its cache lookup, for example by including the expiry time in the cached element. The key itself can be the assertion ID; we can be more strict about this since applications can quite easily construct aOneTimeUserConditionValidatorif they want different behavior.For passivity reasons, this is strictly an opt-in feature; for applications not using this feature, they remain responsible for validating
OneTimeUseelements as they already are today.Please include unit tests, JavaDoc, and reference documentation.