You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by John Holman <j....@qmul.ac.uk> on 2002/02/01 22:56:44 UTC
{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.
Re: {PATCH] Enhanced JNDI realm
Posted by Tony Dahbura <to...@dahbura.com>.
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 <j....@qmul.ac.uk>
> > To: craigmcc@apache.org
> > Cc: tomcat-dev@jakarta.apache.org
> > 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: {PATCH] Enhanced JNDI realm
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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 <j....@qmul.ac.uk>
> To: craigmcc@apache.org
> Cc: tomcat-dev@jakarta.apache.org
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>