Craig I understand (and prefer!) the "bind" approach to authentication. Its the two approaches to role retrieval that has me puzzled.
John At 17:08 08/01/02, Craig R. McClanahan wrote: >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]>
