tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 9705] - Extra LDAP searches occur during JNDIRealm authentication
Date Sun, 16 Jun 2002 23:06:04 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9705>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9705

Extra LDAP searches occur during JNDIRealm authentication

j.g.holman@qmul.ac.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From j.g.holman@qmul.ac.uk  2002-06-16 23:06 -------
There are actually two issues here.

For the first issue, this is the intended behaviour. The "extra search" is the 
result of a call to getAttributes() on the directory context. Although it is 
true that this does not actually return any useful information, some such call 
is needed to make JNDI attempt to rebind as the user. (Binding in Sun's JNDI 
LDAP provider is lazy - just changing the credentials in the directory context 
is not enough to make it happen). By the way ldapsearch should not return "no 
such object" for the equivalent search - perhaps the base was not set correctly.

The second issue is also by design. The realm is bound as the administrator, or 
anonymously if no admin username/password is given, whenever it searches for a 
user entry, retrieves a role attribute in a user entry, or searches for roles. 
It may sometimes be possible to avoid the rebind, if users have sufficient 
permissions, but not in the general case. The cost of a rebind in LDAP v3 is 
actually quite small, since the same connection is used throughout, so the 
potential savings are probably quite small. Also it seems a bit cleaner to have 
all these operations performed as the same, known, user and to have the 
persistent connections in a known state following the authentication epsiode 
(and especially if a connection pool is used later). Incidentally, other LDAP 
authentication software such as PADL's pam_ldap seem to behave similarly.

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message