JDBCRealm credential expiry enforcement gap between 9.0.29 and 9.0.30

JDBCRealm relies on a DataSource to validate usernames and passwords, but does not enforce password expiry by default. Administrators seeking to integrate credential expiry must bridge this gap between the realm’s authentication flow and the underlying database’s password expiry timestamps.

The core uncertainty lies in version‑specific support: Tomcat 9.0.30 introduced CredentialExpiredEvent, yet earlier 9.0.x releases lack built‑in expiration handling, requiring custom valves or filters to reject authentication after expiry.

This inconsistency complicates least‑privilege enforcement, as misconfigured DataSource properties could inadvertently expose database credentials or bypass realm checks.

Given these constraints, what approach should be standardized for consistent credential expiry validation across Tomcat 9.0 versions? Is the CredentialExpiredEvent sufficient for programmatic rejection, or must custom logic intercept the authentication cycle? How should password expiry timestamps in the user table be mapped to realm‑level expiry checks without violating least‑privilege boundaries?