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