This sounds excellent. I appreciate the ability to specify which attribute to
match: I plan to use "mail" in a current application.
I wonder if it wouldn't be useful to permit a principal or a credential to be an
attribute in the user's (subject's) own entry, e.g., "creditbalance." (For some
types of data, I wonder if it may be more efficient to maintain it "distributed"
in subjects' entries rather than in a possibly very large and dynamic attribute
list.)
(Perhaps it's obvious, but I'll mention that I'm a bit uncertain about the
distinction and appropriate practical uses of "principals" versus "credentials".
)
Does this model handle "dynamic" groups, by which I mean a reference to a
method/algorythm/formula computed at runtime, like "member of ou=myDepartment",
or "person entries with creditbalance > 10000" ? I understand this can be
achieved by referring to an attribute that stores a URI that includes an LDAP
query string.
In any case, this authenticator is a very exciting contribution.
Martin
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.
>
> 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.
