Connection failures after credential expiry for JNDI JDBC DataSource
0 reputation · 26 Oct 2022, 14:25 UTC
Designing least-privilege authentication for a JNDI JDBC resource in Tomcat 9.x and 10.x raises questions about credential lifecycle and pool behavior. JNDI resources defined in server.xml are resolved at startup, and changes typically require a restart unless the JNDI environment is reloaded via JMX.
Tomcat passes the configured username and password to the JDBC driver, and expired credentials are documented to cause connection failures. The pool does not automatically re-authenticate after a credential change, which can leave existing connections stale. Tomcat 10 adds a factory attribute that permits a custom javax.naming.spi.ObjectFactory to implement authentication logic.
For a least-privilege setup with rotatable credentials, the interaction between startup resolution, pool staleness, and custom factories is unclear.
Does a JNDI JDBC DataSource pick up new credentials without a full server restart? Can a custom factory in Tomcat 10 avoid clear-text credentials in server.xml while still satisfying the DefaultJndiResourceFactory type validation? What is the documented behavior when credentials expire for an already bound resource?
