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