ffang commented on PR #3637:
URL: https://github.com/apache/cxf/pull/3637#issuecomment-6452952470
Thanks @coheigea, this looks good to me. One thing worth noting about how
long the ID stays in the cache:
With the default `cxf-rs-security-replay-jcache.xml`, entry expiry comes
from WSS4J's `EHCacheExpiry`. If the expiry is more than `MAX_TTL` (12 hours)
in the future, it doesn't use the expiry or cap it at 12 hours. It falls back
to `DEFAULT_TTL` (1 hour):
```java
if (expiry == null || expiry.isBefore(now) ||
expiry.isAfter(now.plusSeconds(MAX_TTL))) {
return Duration.of(DEFAULT_TTL, ChronoUnit.SECONDS);
}
```
So an assertion whose `NotOnOrAfter` is, say, 24 hours away is only cached
for 1 hour, and can be replayed for the remaining 23 hours. SAML SSO has the
same behaviour, and bearer assertions for the token endpoint are normally
short-lived, so I don't think this blocks the PR. Still, it might be worth
either:
- mentioning it in the `setReplayCache` Javadoc, so deployments that accept
long-lived assertions know about it, or
- rejecting assertions whose expiry is beyond what the cache can hold when a
replay cache is set (perhaps with a configurable maximum lifetime on
`SamlOAuthValidator`, since a custom cache may have different limits).
What do you think?
Best Regards
Freeman
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
