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.
