JDBCRealm credential expiry enforcement gap between 9.0.29 and 9.0.30

JDBCRealm authenticates users by querying a DataSource for credentials and associated roles. It does not enforce password expiry by default, and the gap between Tomcat 9.0.29 and 9.0.30 illustrates how version-specific changes can leave administrators without a consistent enforcement path.

Likely explanation vs confirmed facts

• Confirmed: JDBCRealm has no built-in password-expiry check. Authentication succeeds as long as the DataSource returns a matching username and password hash, regardless of any expiry timestamp stored in the user table.
• Likely: Tomcat 9.0.30 may introduce a CredentialExpiredEvent class, but its existence and behavior are not verified in this knowledge base. If present, the event appears to be a notification hook rather than a mechanism that automatically rejects authentication.
• Confirmed: Regardless of the Tomcat version, credential rejection must occur during the authentication cycle, before role mapping or resource access, otherwise an expired credential could be used to reach protected resources.

Standardized approach for consistent expiry validation

1. Add a single UTC password-expiry column (e.g., password_expiry_utc) to the table authenticated by JDBCRealm, or use a read-only side table mapped by the same query.
2. Configure the realm's DataSource query to select username, password, and the new expiry column. Grant the DataSource user SELECT-only privilege on those columns; prohibit UPDATE, DDL, or access to unrelated tables.
3. In the authentication interceptor (valve, filter, or custom Authenticator), after the DataSource authentication succeeds, compare the stored expiry timestamp against the current time using a consistent time source. If expiry <= now, reject the attempt with a generic 401 Unauthorized or 403 Forbidden response that does not disclose whether the password expired or was incorrect.
4. Log the expiry check server-side. Do not return expiry details to the client; maintain least-privilege boundaries by keeping expiry metadata out of the authentication response.
5. Deploy the same custom Realm/Valve/Authenticator configuration across all Tomcat nodes. Verify in server.xml or <Context> that the component is active on every instance.

To determine whether the CredentialExpiredEvent can replace custom interception, please confirm the exact Tomcat 9.0.x release and whether the CredentialExpiredEvent class is present in its source artifacts. This detail decides if event-based rejection is sufficient or if the interception pattern above is required.