Motivation
Both kasKeyCache and kasAllowlistCache use hardcoded 5-minute TTLs with no configurability, no central flush mechanism, and no audit logging for cache hits/misses. Customer environments need the ability to configure, manage, and flush these caches.
Raised in #3898 by @jrschumacher.
Requirements
- Configurable TTL for
kasKeyCache and kasAllowlistCache
- Central way to flush/invalidate caches
- Audit logging for cache hits and misses
- Consistent behavior across both caches
Related: #3899 (mutex/concurrency safety for both caches)
Notes
https://github.com/opentdf/web-sdk/ and https://github.com/opentdf/java-sdk/ both have the same issues with cache.
In case of WebSDK, Key Cache doesn't even have a TTL
Motivation
Both
kasKeyCacheandkasAllowlistCacheuse hardcoded 5-minute TTLs with no configurability, no central flush mechanism, and no audit logging for cache hits/misses. Customer environments need the ability to configure, manage, and flush these caches.Raised in #3898 by @jrschumacher.
Requirements
kasKeyCacheandkasAllowlistCacheRelated: #3899 (mutex/concurrency safety for both caches)
Notes
https://github.com/opentdf/web-sdk/ and https://github.com/opentdf/java-sdk/ both have the same issues with cache.
In case of WebSDK, Key Cache doesn't even have a TTL