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=11210>.
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=11210

JNDIRealm successfully authenticated a non-existing user on iPlanet Directory Server





------- Additional Comments From [EMAIL PROTECTED]  2002-07-27 15:08 -------
I downloaded the iPlanet/Netscape/Mozilla Directory SDK 4.1 from Sun and
replicated the problem, which is due to a failure of this LDAP provider
(com.netscape.jndi.ldap.LdapContextFactory) to conform to the JNDI specification.

Section 6.6.2 of the JNDI 1.2 spec on the timeliness of modifications to the
context environment says that changes to an environment property should be
effective the next time an operation using that property is envoked. JNDIRealm
relies on this to authenticate by binding as the user - it changes the principal
and password properties and then carries out a search operation with the new
environment. This all works as expected when using the default LDAP provider
from Sun.

The iPlanet implementation, on the other hand, seems to ignore any change to
environment properties when the changed property pertains to the connection.
(This discrepancy is hinted at in the section on JNDI Environmental Properties
in the Netscape documentation). Thus it never even attempts to rebind as the user.

This should really be fixed by whoever is now maintaining the Netscape provider,
but I have a feeling that may not be trivial. So I've just attached a patch to
JNDIRealm to work around the problem. This invokes reconnect() on the context to
force an immediate rebind both when switching from administrator to user
credentials for authentication and when switching from user to administrator
credentials to search for user entries and role information. 

One, perhaps slight, downside is that the context must now be an LdapContext
instead of the more generic DirectoryContext. On the other hand the realm is
slightly more efficient than before when using the Sun LDAP provider. With the
Netscape provider, it works correctly, but is rather inefficient since this
provider closes the LDAP connection and creates a new one when reconnect() is
invoked instead of keeping the same connection and rebinding with the new
credentials.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to