John,
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 JNDIRealm.java?
For changes this big, I get a little gunshy about merging diffs.
Thanks,
Craig
On Fri, 1 Feb 2002, John Holman wrote:
> Date: Fri, 01 Feb 2002 21:56:44 +0000
> From: John Holman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
