I think what Craig is referring to for role retrieval is the idea that the roles a user is a member of are stored in the user's directory entry. This approach allows entry to a group by adding that attribute to the specific user entry.
The role retrieval would have the option to look a list of roles or to look at the user's entry to determine role membership. Tony John Holman wrote: > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
