tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: {PATCH] Enhanced JNDI realm
Date Fri, 15 Feb 2002 21:45:32 GMT

Sorry it took so long to respond to this ... life has been busier than I
would have believed possible.

I've reviewed the patch, and the changes seem reasonable.  Can you do me a
favor, though, and send me a complete updated version of
For changes this big, I get a little gunshy about merging diffs.


On Fri, 1 Feb 2002, John Holman wrote:

> Date: Fri, 01 Feb 2002 21:56:44 +0000
> From: John Holman <>
> To:
> Cc:
> Subject: {PATCH] Enhanced JNDI realm
> Craig
> I've attached a patch to enhance the current JNDI realm implementation.
> This includes three features that have been requested a number of times and
> appear in the draft functional specification:
> ** the realm can authenticate by binding to the directory as the user. This
> mode of operation is usually to be preferred unless HTTP digest
> authentication is required. The realm will automatically authenticate in
> this way if the "userPassword" configuration attribute is not specified.
> The "connectionName" and "connectPassword" properties are used
> when searching the directory or retrieving role information. In this mode,
> anonymous authentication is often sufficient, in which case these need not
> be specified.
> ** the realm can search the directory for the user's entry. It will do this
> if the "userPattern" configuration attribute is not specified.
> Three new configuration parameters control the search for the user's
> directory entry:
> userSearch - a pattern specifying the LDAP search filter for selecting
> users. Use {0} to substitute in the username.
> userBase - the base element for user searches. If not specified the top
> level element in the directory context will be used.
> useSubtree - set to true if you want user searches to search subtrees of
> the element selected by userBase. The default value of false causes only
> the top level element to be searched.
> ** the realm can combine roles held as the values of an attribute in the
> user's entry with those retrieved from a search for roles. The search for
> roles takes place as before. If the roleSearch configuration attribute is
> not specified the realm will look only in the user's entry for roles.
> This feature uses one new configuration attribute:
> userRoleName - the name of an attribute in the user's entry containing the
> names of roles. If not specified the directory is searched for roles as before.
> Note that the new configuration interface is backwards compatible with the
> current JNDIRealm. For existing users the realm will behave just as it did
> before - no configuration changes are required. The existing documentation
> is still accurate about the subset of functionality it describes.
> Here is a sample realm configuration that demonstrates all three new
> features. It is assumed that an anonymous bind is sufficient to search the
> directory for the user
> and retrieve the role information. The user is found by searching the
> directory and authenticated by binding to the directory with the
> credentials presented by the user. Role names are contained both in the
> "memberOf" attribute of the user's own directory entry and in the "cn"
> attribute of group entries to which the user belongs
>        <Realm className="org.apache.catalina.realm.JNDIRealm"
>              debug="99"
> 	  connectionURL="ldap://localhost:389"
> 	  userBase="ou=people,dc=mycompany,dc=com"
> 	  userSearch="(uid={0})"
> 	  userRoleName="memberOf"
> 	  roleSearch="(uniqueMember={0})"
> 	  roleBase="ou=groups,dc=mycompany,dc=com"
> 	  roleName="cn"
> 	  roleSubtree="true"
>        />
> I've not addressed issues of connection management etc in this patch,
> though there is certainly room for improvement (context pooling etc). In a
> previous message you mentioned leveraging the "global JNDI resources"
> capabilities for that, and Tony Danbura has also expressed an interest in
> this area. However the enhancements in this patch are independent of that
> issue, and should not complicate it. In particular, note that the "bind
> mode" functionality is implemented in a way that still uses a single
> directory context that can be returned to the pool. This is achieved by
> changing the security environment of the context before and after binding,
> rather than creating a different context for the bind. With an LDAP v3
> server this should be an efficient approach since the underlying connection
> to the directory server does not change. An LDAP v2 server must create a
> new connection for each bind operation, so context pooling will not be so
> effective, but that does not affect the logic.
> I'd be very grateful if you would take a look at this patch and hopefully
> submit it. If it is accepted I promise I'll update the documentation to
> cover the new features!
> Thanks, John.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message