The downside to binding with the supplied credentials is that it chews up a
file descriptor. For light loads, it's not an issue. For heavy loads, it can
be a big issue. If the app server binds administratively, you can get by
with two connections, one for reading and one for writing. Or even one, if
you're not replicating LDAP.
All in all, making it configurable is probably a good idea.
> -----Original Message-----
> From: Ellen Lockhart [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 13, 2001 12:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: JNDI/LDAP realm
>
>
> I preferred binding to the directory with supplied
> credentials because it
> allows the realm implementation to use an anonymous password
> for the rest of
> what it needs.
>
> To allow for DN's in the directory that may not be composed
> of the same
> attributes as other DN's, one thing I was thinking about
> doing to the one I
> submitted was to configure what the login attribute is (cn,
> uid, etc.) and
> search for it (with anonymous login) to get the dn, then bind to the
> directory with the resultant DN and the user-entered password to
> authenticate. This might be a little less efficient than
> just searching and
> getting the password as well, but is more secure than having the root
> password to the ldap server where it might be accessible by someone.
>
>
> ----- Original Message -----
> From: "John Holman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Sunday, May 13, 2001 5:02 AM
> Subject: JNDI/LDAP realm
>
>
> > The current JNDI realm implementation in Tomcat 4 is based on code I
> > submitted, which was subsequently modified and committed by Craig.
> >
> > Two significant changes he made are:
> >
> > - the original code found the DN of the user by searching
> the directory.
> The
> > current implementation, like Ellen Lockhart's recent submission,
> determines
> > the DN by substituting the username into a string.
> >
> > - the original code supported a mode in which the user is
> authenticated by
> > binding to the directory with the supplied credentials (as
> does Ellen's).
> > The code for this was removed, with a comment in the commit
> log that this
> > mode should be supported probably in a separate
> implementation class.
> >
> > I did comment on this in an earlier message, but got no
> response - so I'm
> > trying again now there is another little wave of interest :)
> >
> > Determining the DN. The pattern substitution method in the current
> > implementation is obviously more efficient when applicable
> but the search
> > method is more general. For example, unlike the current
> implementation,
> > search can handle the following common use cases:
> >
> > - users are stored within multiple nodes in the directory
> (e.g. they may
> be
> > held under different
> > organisational units)
> >
> > - the attribute used in distinguished names is not the same
> as that the
> user
> > enters into the basic authentication dialog box (e.g. the
> user might enter
> > mail address as the username rather than uid; the directory
> might use
> > commonName as a component of distinguished names rather than uid).
> >
> > So there are really two orthogonal issues for user
> authentication each
> with
> > two options:
> >
> > - how the dn for the user is determined (configuration template vs
> directory
> > search)
> > - how authentication is done (system login vs binding as the user)
> >
> > I think it's important that Tomcat supports the missing
> combinations of
> > options. In fact, the most common strategy when using a
> directory for
> > authentication is probably "search then bind", neither
> component of which
> is
> > supported by the current implementation. For example, this is the
> strategy
> > taken by pam_ldap and by the auth_ldap Apache module.
> >
> > I'd be happy to have a go at adding the missing
> functionality, but would
> > like some feedback first as to whether people think this is
> a good idea.
> > Also opinions as to whether we should have one, two or even
> four classes
> to
> > implement the different combinations (with multiple classes
> maybe derived
> > from a base JNDIRealm class). We should take into account
> which variation
> is
> > likely to lead to the simplest and clearest configuration
> documentation
> ...
> >
> > John.
> >
> >
>
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named. Any use, copying or disclosure by any other person is strictly
prohibited. If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
