JNDI realm

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

The log of Craig's initial commit for JNDIRealm says:

> TODO:  Support an operational mode where the Realm attempts to bind to the
> directory server using the user's username and password (instead of a
> system administrator username and password).  This is a different enough
> style that it probably should be a separate implementation class.

In the initial commit it is assumed that the user dn can be expressed as a
pattern specified in the server.xml configuration in which the username is
substituted. This is an efficient approach when the assumption is justified,
but quite often it is not:

- users may be held in a tree in the directory (e.g. under different
organizational units)

- the attribute used for naming in distinguished names may not be 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
may use commonName in distinguished names rather than uid).

So I suggest we support a mode where the user's dn is found by a directory
search on the value of an arbitrary attribute. This "search then bind"
approach is taken by at least two two other popular applications: pam_ldap
and the auth_ldap module for Apache. Compatibility with the latter means
that people could always use the same directory data for access control to
static pages (via auth_ldap) and to dynamic ones (via Tomcat's JNDIRealm).

Thus there are really two orthogonal options for user authentication

- how the dn for the user is determined (configuration template vs directory
search)
- how the authentication is done (system vs user login)

I think we should support all four variations. Four implementation classes
are a possibility, and would avoid a little run-time overhead, but involves
some code duplication and configuration could be a little awkward to
describe. Another possibility is to implement within the same class, in
which case the processing done by getUserDN() will vary depending upon which
configuration properties are defined. For example, if property
"userDNFormat" is defined, the DN is formed by substituting the username
into a template; otherwise properties such as "userFilter", "userBase" and
"userSubtree" define a search for the DN (as in my original submission).
Similarly if "userPassword" is defined the system login approach is used;
otherwise authentication is done by binding as the user. Either way (or
indeed if we think it'd be better to have two implementation classes with
one option varying within the class) if there's interest I'd be willing to
have a go at it.

On a different but related topic,  I wonder whether it is sensible to assume
that user authentication and the determination of roles always use the same
mechanisms. For example one might want to use a directory service for
authentication but look up roles in a database - or vice versa. Obviously
supporting this would require significant refactoring to the Realm
implementation in general.

Finally I've looked (e.g. in the servlet spec) but can't find a clear
statement about what Principal.getName() should return. The current
implementation returns the username (ie same as getRemoteUser()). Might the
distinguished name be more appropriate when a directory service is used?

John.

Re: JNDI realm

[Antony Bowesman <ad...@teamware.com>]

John Holman wrote:
> 
> On a different but related topic,  I wonder whether it is sensible
> to assume that user authentication and the determination of roles
> always use the same mechanisms. For example one might want to use a
> directory service for authentication but look up roles in a database
> - or vice versa. Obviously supporting this would require significant
> refactoring to the Realm implementation in general.

I agree that authentication and role population are two distinctly
separate issues.  It should not be necessary to have to maintain the
authentication repository every time new J2EE components and roles get
deloyed.  Applying roles to the authentication mechanism also makes it
harder to reassign roles without forcing users to reauthenticate.

> Finally I've looked (e.g. in the servlet spec) but can't find a
> clear statement about what Principal.getName() should return.
> The current implementation returns the username (ie same as 
> getRemoteUser()). Might the distinguished name be more appropriate
> when a directory service is used?

The whole are of Principals in Web/EJB container is unclear.  Servlet
spec and EJB spec only allow a single Principal.  However, JAAS is
currently being pushed into J2EE, both via J2SE, Connector arch. and
J2EE 1.3 spec.  In this case, it would seem getUserPrincipal is likely
to disappear and JAAS Subject be supported instead.

However, currently Principal.getName() can return whatever your
Principal implementation wants it to return.

Rgds
-- 
Antony Bowesman
Teamware Group 
adb@teamware.com
tel: +358 9 5128 2562
fax: +358 9 5128 2705