----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>> To authenticate the
> > user, the directory is first searched for an entry with an attribute
> > matching the given username. An attempt is then made to bind to the
> > directory using the name of that entry and the password.
> >
>
> This is the way that the old Netscape Enterprise Server did it's LDAP
> authentication. I think we should support this mode, as well as a mode
> where the Realm binds with a system username/password and then looks up
> user and password elements in the same way that JDBCRealm gets them from
> the database.
"Search then bind" seems to be the most common approach (e.g. pam_ldap and
the ldap_auth Apache module both authenticate that way). Advantages are that
no priviledges are needed, so it works with an anonymous connection, and
that the directory server can keep arbitrary hashes of the password instead
of the plaintext password without the client having to be concerned. However
I agree we should support the mode where the Realm gets the plaintext
password from the directory server and compares it with the client's
offering.
Incidentally there is an issue about supporting Digest Access
Authentication. In general it cannot be assumed that the plaintext password
will be held in the directory - in fact things are somewhat more secure if
it isn't - but without the plaintext password it isn't (usually) possible
for a Realm to calculate a digest to compare with what the browser sends. In
this implementation the getPassword() method defined in RealmBase always
returns null, and Digest Authentication won't work. The same thing is true
of the JDBCRealm - and presumably Digest Authentication is broken there as
well.
> Note that I've also started refactoring the Realm stuff a little, so that
> things like the GenericPrincipal class can be reused by other Realm
> implementations.
The current implementation uses GenericPrincipal.
> > A role is represented in the directory by an entry with an attribute
whose
> > values identify the users with that role, and optionally with an
attribute
> > whose value is the name of the role. In an LDAP directory a role entry
might
> > have a uniqueMember or member attribute to hold the distinguished names
of
> > the users. However other attribute types could be used, and the values
could
> > be usernames instead of DNs. In the current implementation, all the
roles
> > associated with a user are retrieved when the user is first
authenticated
> > and then cached in the Principal object.
> >
>
> That's the way I would do it as well. Tomcat will cache the Principal
> (assuming the app is using sessions, which is the usual case) so this
> information can be used later to answer isUserInRole() type questions.
In the interests of flexibility, should we also provide the option of
representing roles as values of an attribute within the user entry?
Also in the interests of flexibility, the Realm can now be configured with
general filters for user and role searches:
userSearchFilter - the filter to use when searching for a user entry. {0}
will be replaced with the value of the username. Default: (uid={0})
roleSearchFilter - the filter to use when searching for a user's roles. {0}
will be replaced with the distinguished name of the user entry. {1} will be
replaced with the username. . Default: (|(uniqueMember={0})(member={0}))
The roleValueIsDN, roleMemberAttribute and userNameAttribute configuration
parameters are now redundant (though it might be worth keeping some of them
to simplify common cases).
Given that there are now at least two other offerings covering similar
ground, I'm really not sure how to proceed. So I've attached the current
code to this message - I hope that's acceptable. It seemed better to make it
available now than to carry on in isolation.
John.
JNDIRealm.java
