John:
If you want to hold off about a week, I will have the pooling code done and we can
merge it with your final package and send them all in at once.....
Tony
"Craig R. McClanahan" wrote:
> 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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
