On Mon, 2 Apr 2001, John Holman wrote:
> One of the action items in the Catalina status document is a JNDI realm.
> I've been working on this recently and wonder whether what I've done would
> be useful to the project - though I'm not sure how best to get involved.
> Incidentally, the status document lists James W as a volunteer for this
> item. I sent James a message a few days ago asking about progress but
> haven't received a response yet.
>
JNDI realms must be a highly sought after feature :-). Two people on
TOMCAT-USER proposed code over for this in the last couple of days as
well.
> Anyway, this is what I've done/plan to do. The current implementation
> follows the general pattern of the existing JDBCRealm. It is assumed that
> user and role information is held in a directory server. 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.
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.
> 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.
> To accommodate the different ways that user and role information can be
> represented in the directory a number of configuration attributes are
> needed - though fortunately most can have defaults. Here is a possible set:
>
> connectionURL - the connection URL to be passed to the JNDI provider.
> Usually this will be an LDAP URL specifying the hostname and port of the
> directory server and optionally the name of the root naming context. This
> attribute is required. Example: ldap://ldap.acme.com:389
>
> contextFactory - the class name of the inital context factory to use.
> Default: com.sun.jndi.ldap.LdapCtxFactory
>
> userSearchBase - the name of the context (relative to the root context)
> within which to search for users.
> This attribute is required. Example: ou=people
>
> userNameAttribute - the name of the attribute whose value will be matched to
> the given username. Default: "uid"
>
> userSearchSubtree - if true the subtree starting at userSearchBase will be
> searched for a user with the given username. If false a one-level search is
> performed. Default: "false"
>
> roleSearchBase - the name of the context (relative to the root context)
> within which to search for roles. This attribute is required. Example:
> ou=groups
>
> roleMemberAttribute - the name of the attribute whose values identify the
> users with that role. Default: uniqueMember.
>
> roleNameAttribute - the name of the attribute whose value is the name of the
> role. If not specifed, a role name is constructed from the leftmost
> component of the name of the directory entry. (This will probably only work
> for LDAP-style distinguished names).
>
> roleSearchSubtree - if "true" the whole subtree starting at roleSearchBase
> is searched for roles. If "false" a one-level search is performed. Default:
> "false"
>
> roleValueIsDN - if "true" the values of the roleNameAttribute are the
> distinguished names of the users. If "false" they are usernames. Default:
> "true" [ not yet implemented - only DNs handled ]
>
> useSSL - whether to make an SSL connection to the directory server. Default:
> "false". [not yet implemented]
>
> connectionName - the dn to use when connecting to the directory server. If
> not specified an anonymous connection is used. [ not yet implemented ]
>
> connectionPassword - the password to use when connecting to the directory
> server. If not specified an anonymous connection is used. [ not yet
> implemented ]
>
> I'd welcome any feedback.
>
Sounds good in general.
> John.
>
>
>
Craig McClanahan
