Hi John, Some LDAP servers are configured to never allow the userPassword attribute be accessed at all. The only way to authenticate, in this approach, is to attempt an LDAP "bind" using the username and password values specified by the user of the web application -- so that each authentication attempt becomes a separate bind. If the bind succeeds, authentication was successful -- otherwise it failed.
I know that the old Netscape Enterprise Server used LDAP this way, and I imagine that the current iPlanet ones do as well. But we don't currently support this mode in JNDIRealm. As an additional new feature, I am looking to leverage the "global JNDI resources" capabilities (in the HEAD branch only) that would let us declare a global connection pool (for either JNDI connections or JDBC connections) in server.xml, and then use it from within a Realm *and* an application if the system administrator sets things up to allow this. That should let us improve overall performance -- at least on the "log in with the system username/password" mode that we currently support. Craig On Tue, 8 Jan 2002, John Holman wrote: > Date: Tue, 08 Jan 2002 14:25:16 +0000 > From: John Holman <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Functional spec for JNDI Realm > > Craig > > After a long delay, I'm looking at your proposed functional spec for the > Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the > "Adminstrator Login Mode Functionality" section: > > > The following approaches should be supported [ for retrieving the roles > associated with an authenticated user ] > > > > Retrieve a specified attribute (possibly multi-valued) from an LDAP > search expression, with a replacement placeholder > > for the DN or username of the user.[Current] > > > > Retrieve a set of role names that are defined implicitly (by selecting > principals that match a search pattern) rather > > than explicitly (by finding a particular attribute value). [Requested] > > The existing code certainly implements the first approach, which I assume > could be rephrased as > > Retrieve the values of a specified attribute from all directory entries > matching an LDAP search filter expression. The search expression is > constructed by substituting the user's DN and/or username into a string > pattern specified as the roleSearch configuration property. > > However I guess I don't understand what you mean by the second approach. Do > you have a specific example? I would have thought that the current approach > covers all use cases (although admittedly the implementation may not be > optimal for the special case in which role names are held explicitly as the > values of an attribute in the user's directory entry). > > Cheers, John. > > > > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
