You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Justin Bertram (Jira)" <ji...@apache.org> on 2024/04/04 15:36:00 UTC
[jira] [Created] (ARTEMIS-4712) Remove LDAP connection pooling
Justin Bertram created ARTEMIS-4712:
---------------------------------------
Summary: Remove LDAP connection pooling
Key: ARTEMIS-4712
URL: https://issues.apache.org/jira/browse/ARTEMIS-4712
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Justin Bertram
Assignee: Justin Bertram
The {{LDAPLoginModule}} supports connection pooling, but there have been reports of weird behavior with pooling vs. without. For example, with pooling once a login failure occurs subsequent login attempts also fail - even if credentials are valid. However, without pooling this behavior is never seen.
Upon further investigation the [Oracle documentation|https://docs.oracle.com/javase/jndi/tutorial/ldap/connect/pool.html] says this:
bq. Pooled connections are intended to be reused. Therefore, if you plan to perform operations on a Context instance that might alter the underlying connection's state, then you should not use connection pooling for that Context instance. For example, if you plan to invoke the Start TLS extended operation on a Context instance, or plan to change security-related properties (such as "java.naming.security.principal" or "java.naming.security.protocol") after the initial context has been created, you should not use connection pooling for that Context instance because the LDAP provider does not track any such state changes. If you use connection pooling in such situations, you might be compromising the security of your application.
The {{LDAPLoginModule}} does, in fact, modify the {{java.naming.security.principal}} of the {{Context}} (i.e. in the {{bindUser}} method). Although the {{Context}} is immediately reset to the original values (ostensibly restoring normal pool behavior) the pooling functionality should be removed in an abundance of caution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)