JNDI/LDAP realm

[John Holman <j....@qmw.ac.uk>]

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.

Re: JNDI/LDAP realm

[Torgeir Veimo <to...@vertech.no>]

John Holman wrote:
> 
> > 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.

+1

> The only advantage I can see
> for having the realm retrieve the password is that it makes http digest
> authentication possible, provided that the plaintext password or a suitable
> hash is stored in the directory. 

I think that http digest authentication in theory is possible with
authentication using an LDAP bind. The tricky details are in using the
nonce & realm from the LDAP server in the initial challenge, and not
having the LDAP client code touch the digested answer from the client
before sending it to the LDAP server.

I would like to add a third feature, namely to be able to reuse the
authentication information from the servlet container in a "resource
connector", eg. an LDAP connection pool so that a web application could
ask for authenticated connections to the LDAP server without having to
deal with username and passwords itself. Currently this is not possible
with tomcat4.0beta.

-- 
- Torgeir

Re: JNDI/LDAP realm

[John Holman <j....@qmw.ac.uk>]

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

Yes - I think binding is the better approach in general. Also the directory
can then contain password hashes rather than plaintext passwords without the
Tomcat realm having to know about the details. The only advantage I can see
for having the realm retrieve the password is that it makes http digest
authentication possible, provided that the plaintext password or a suitable
hash is stored in the directory. Whether any web browser actually supports
digest authentication is another matter ...

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

That too is my preferred approach, and it's how the code I originally
submitted works.

Re: JNDI/LDAP realm

[Ellen Lockhart <el...@home.com>]

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" <j....@qmw.ac.uk>
To: <to...@jakarta.apache.org>
Cc: <cr...@apache.org>
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.
>
>