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/01/08 15:25:16 UTC
Functional spec for JNDI Realm
Craig
After a long delay, I'm looking at your proposed functional spec for the
Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the
"Adminstrator Login Mode Functionality" section:
> The following approaches should be supported [ for retrieving the roles
associated with an authenticated user ]
>
> Retrieve a specified attribute (possibly multi-valued) from an LDAP
search expression, with a replacement placeholder
> for the DN or username of the user.[Current]
>
> Retrieve a set of role names that are defined implicitly (by selecting
principals that match a search pattern) rather
> than explicitly (by finding a particular attribute value). [Requested]
The existing code certainly implements the first approach, which I assume
could be rephrased as
Retrieve the values of a specified attribute from all directory entries
matching an LDAP search filter expression. The search expression is
constructed by substituting the user's DN and/or username into a string
pattern specified as the roleSearch configuration property.
However I guess I don't understand what you mean by the second approach. Do
you have a specific example? I would have thought that the current approach
covers all use cases (although admittedly the implementation may not be
optimal for the special case in which role names are held explicitly as the
values of an attribute in the user's directory entry).
Cheers, John.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Functional spec for JNDI Realm
Posted by John Holman <j....@qmul.ac.uk>.
Tony
t 02:58 09/01/02, Tony Dahbura wrote:
>I think what Craig is referring to for role retrieval is the idea that the
>roles a
>user is a member of are stored in the user's directory entry. This
>approach allows
>entry to a group by adding that attribute to the specific user entry.
>
>The role retrieval would have the option to look a list of roles or to
>look at the
>user's entry to determine role membership.
It is certainly possible to hold the roles as the values of an attribute in
the user's directory entry. However, as in fact I mentioned in my original
query to Craig, this is a special case that is already covered by the
current approach. For example, if the roles are held in an attribute of the
user called "roles" whose values are the names of the roles the user is a
member of, the current realm might be configured with
roleName="roles"
roleSearch="(uid = {1})"
roleBase= [ dn for the root of the directory tree containing the user entries ]
The search for roles would find the user's directory entry, since {1} is a
placeholder for the username, and retrieve the values of the roleNames
attribute.
Of course some optimisation is possible in this special case. For example,
in "Administrator Login" mode the roles could be retrieved at the same time
as the password, although this would complicate the code to some extent.
I'd agree that we should perhaps recognize this special case by saying that
if the roleBase and roleSearch parameters are not defined then the roles
are assumed to be held explicitly in the user's entry. This would simplify
configuration for the user. However, I don't know how common this use case
is in practice. As far as I know, there is no standard attribute for this
purpose, so the user would have the extend the directory schema to
accommodate it, which might be a deterrant to some.
John.
>Tony
>
>
>John Holman wrote:
>
> > Craig
> >
> > I understand (and prefer!) the "bind" approach to authentication. Its the
> > two approaches to role retrieval that has me puzzled.
> >
> > John
> >
> > At 17:08 08/01/02, Craig R. McClanahan wrote:
> > >Hi John,
> > >
> > >Some LDAP servers are configured to never allow the userPassword attribute
> > >be accessed at all. The only way to authenticate, in this approach, is to
> > >attempt an LDAP "bind" using the username and password values specified by
> > >the user of the web application -- so that each authentication attempt
> > >becomes a separate bind. If the bind succeeds, authentication was
> > >successful -- otherwise it failed.
> > >
> > >I know that the old Netscape Enterprise Server used LDAP this way, and I
> > >imagine that the current iPlanet ones do as well. But we don't currently
> > >support this mode in JNDIRealm.
> > >
> > >As an additional new feature, I am looking to leverage the "global JNDI
> > >resources" capabilities (in the HEAD branch only) that would let us
> > >declare a global connection pool (for either JNDI connections or JDBC
> > >connections) in server.xml, and then use it from within a Realm *and* an
> > >application if the system administrator sets things up to allow this.
> > >That should let us improve overall performance -- at least on the "log in
> > >with the system username/password" mode that we currently support.
> > >
> > >Craig
> > >
> > >
> > >On Tue, 8 Jan 2002, John Holman wrote:
> > >
> > > > Date: Tue, 08 Jan 2002 14:25:16 +0000
> > > > From: John Holman <j....@qmul.ac.uk>
> > > > To: craigmcc@apache.org
> > > > Cc: tomcat-dev@jakarta.apache.org
> > > > Subject: Functional spec for JNDI Realm
> > > >
> > > > Craig
> > > >
> > > > After a long delay, I'm looking at your proposed functional spec
> for the
> > > > Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the
> > > > "Adminstrator Login Mode Functionality" section:
> > > >
> > > > > The following approaches should be supported [ for retrieving
> the roles
> > > > associated with an authenticated user ]
> > > > >
> > > > > Retrieve a specified attribute (possibly multi-valued) from an LDAP
> > > > search expression, with a replacement placeholder
> > > > > for the DN or username of the user.[Current]
> > > > >
> > > > > Retrieve a set of role names that are defined implicitly (by
> selecting
> > > > principals that match a search pattern) rather
> > > > > than explicitly (by finding a particular attribute value).
> [Requested]
> > > >
> > > > The existing code certainly implements the first approach, which I
> assume
> > > > could be rephrased as
> > > >
> > > > Retrieve the values of a specified attribute from all directory entries
> > > > matching an LDAP search filter expression. The search expression is
> > > > constructed by substituting the user's DN and/or username into a string
> > > > pattern specified as the roleSearch configuration property.
> > > >
> > > > However I guess I don't understand what you mean by the second
> approach. Do
> > > > you have a specific example? I would have thought that the current
> approach
> > > > covers all use cases (although admittedly the implementation may not be
> > > > optimal for the special case in which role names are held
> explicitly as the
> > > > values of an attribute in the user's directory entry).
> > > >
> > > > Cheers, 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Functional spec for JNDI Realm
Posted by Tony Dahbura <to...@dahbura.com>.
I think what Craig is referring to for role retrieval is the idea that the roles a
user is a member of are stored in the user's directory entry. This approach allows
entry to a group by adding that attribute to the specific user entry.
The role retrieval would have the option to look a list of roles or to look at the
user's entry to determine role membership.
Tony
John Holman wrote:
> Craig
>
> I understand (and prefer!) the "bind" approach to authentication. Its the
> two approaches to role retrieval that has me puzzled.
>
> John
>
> At 17:08 08/01/02, Craig R. McClanahan wrote:
> >Hi John,
> >
> >Some LDAP servers are configured to never allow the userPassword attribute
> >be accessed at all. The only way to authenticate, in this approach, is to
> >attempt an LDAP "bind" using the username and password values specified by
> >the user of the web application -- so that each authentication attempt
> >becomes a separate bind. If the bind succeeds, authentication was
> >successful -- otherwise it failed.
> >
> >I know that the old Netscape Enterprise Server used LDAP this way, and I
> >imagine that the current iPlanet ones do as well. But we don't currently
> >support this mode in JNDIRealm.
> >
> >As an additional new feature, I am looking to leverage the "global JNDI
> >resources" capabilities (in the HEAD branch only) that would let us
> >declare a global connection pool (for either JNDI connections or JDBC
> >connections) in server.xml, and then use it from within a Realm *and* an
> >application if the system administrator sets things up to allow this.
> >That should let us improve overall performance -- at least on the "log in
> >with the system username/password" mode that we currently support.
> >
> >Craig
> >
> >
> >On Tue, 8 Jan 2002, John Holman wrote:
> >
> > > Date: Tue, 08 Jan 2002 14:25:16 +0000
> > > From: John Holman <j....@qmul.ac.uk>
> > > To: craigmcc@apache.org
> > > Cc: tomcat-dev@jakarta.apache.org
> > > Subject: Functional spec for JNDI Realm
> > >
> > > Craig
> > >
> > > After a long delay, I'm looking at your proposed functional spec for the
> > > Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the
> > > "Adminstrator Login Mode Functionality" section:
> > >
> > > > The following approaches should be supported [ for retrieving the roles
> > > associated with an authenticated user ]
> > > >
> > > > Retrieve a specified attribute (possibly multi-valued) from an LDAP
> > > search expression, with a replacement placeholder
> > > > for the DN or username of the user.[Current]
> > > >
> > > > Retrieve a set of role names that are defined implicitly (by selecting
> > > principals that match a search pattern) rather
> > > > than explicitly (by finding a particular attribute value). [Requested]
> > >
> > > The existing code certainly implements the first approach, which I assume
> > > could be rephrased as
> > >
> > > Retrieve the values of a specified attribute from all directory entries
> > > matching an LDAP search filter expression. The search expression is
> > > constructed by substituting the user's DN and/or username into a string
> > > pattern specified as the roleSearch configuration property.
> > >
> > > However I guess I don't understand what you mean by the second approach. Do
> > > you have a specific example? I would have thought that the current approach
> > > covers all use cases (although admittedly the implementation may not be
> > > optimal for the special case in which role names are held explicitly as the
> > > values of an attribute in the user's directory entry).
> > >
> > > Cheers, 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: Functional spec for JNDI Realm
Posted by John Holman <j....@qmul.ac.uk>.
Craig
I understand (and prefer!) the "bind" approach to authentication. Its the
two approaches to role retrieval that has me puzzled.
John
At 17:08 08/01/02, Craig R. McClanahan wrote:
>Hi John,
>
>Some LDAP servers are configured to never allow the userPassword attribute
>be accessed at all. The only way to authenticate, in this approach, is to
>attempt an LDAP "bind" using the username and password values specified by
>the user of the web application -- so that each authentication attempt
>becomes a separate bind. If the bind succeeds, authentication was
>successful -- otherwise it failed.
>
>I know that the old Netscape Enterprise Server used LDAP this way, and I
>imagine that the current iPlanet ones do as well. But we don't currently
>support this mode in JNDIRealm.
>
>As an additional new feature, I am looking to leverage the "global JNDI
>resources" capabilities (in the HEAD branch only) that would let us
>declare a global connection pool (for either JNDI connections or JDBC
>connections) in server.xml, and then use it from within a Realm *and* an
>application if the system administrator sets things up to allow this.
>That should let us improve overall performance -- at least on the "log in
>with the system username/password" mode that we currently support.
>
>Craig
>
>
>On Tue, 8 Jan 2002, John Holman wrote:
>
> > Date: Tue, 08 Jan 2002 14:25:16 +0000
> > From: John Holman <j....@qmul.ac.uk>
> > To: craigmcc@apache.org
> > Cc: tomcat-dev@jakarta.apache.org
> > Subject: Functional spec for JNDI Realm
> >
> > Craig
> >
> > After a long delay, I'm looking at your proposed functional spec for the
> > Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the
> > "Adminstrator Login Mode Functionality" section:
> >
> > > The following approaches should be supported [ for retrieving the roles
> > associated with an authenticated user ]
> > >
> > > Retrieve a specified attribute (possibly multi-valued) from an LDAP
> > search expression, with a replacement placeholder
> > > for the DN or username of the user.[Current]
> > >
> > > Retrieve a set of role names that are defined implicitly (by selecting
> > principals that match a search pattern) rather
> > > than explicitly (by finding a particular attribute value). [Requested]
> >
> > The existing code certainly implements the first approach, which I assume
> > could be rephrased as
> >
> > Retrieve the values of a specified attribute from all directory entries
> > matching an LDAP search filter expression. The search expression is
> > constructed by substituting the user's DN and/or username into a string
> > pattern specified as the roleSearch configuration property.
> >
> > However I guess I don't understand what you mean by the second approach. Do
> > you have a specific example? I would have thought that the current approach
> > covers all use cases (although admittedly the implementation may not be
> > optimal for the special case in which role names are held explicitly as the
> > values of an attribute in the user's directory entry).
> >
> > Cheers, John.
> >
> >
> >
> >
> >
> >
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Functional spec for JNDI Realm
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Hi John,
Some LDAP servers are configured to never allow the userPassword attribute
be accessed at all. The only way to authenticate, in this approach, is to
attempt an LDAP "bind" using the username and password values specified by
the user of the web application -- so that each authentication attempt
becomes a separate bind. If the bind succeeds, authentication was
successful -- otherwise it failed.
I know that the old Netscape Enterprise Server used LDAP this way, and I
imagine that the current iPlanet ones do as well. But we don't currently
support this mode in JNDIRealm.
As an additional new feature, I am looking to leverage the "global JNDI
resources" capabilities (in the HEAD branch only) that would let us
declare a global connection pool (for either JNDI connections or JDBC
connections) in server.xml, and then use it from within a Realm *and* an
application if the system administrator sets things up to allow this.
That should let us improve overall performance -- at least on the "log in
with the system username/password" mode that we currently support.
Craig
On Tue, 8 Jan 2002, John Holman wrote:
> Date: Tue, 08 Jan 2002 14:25:16 +0000
> From: John Holman <j....@qmul.ac.uk>
> To: craigmcc@apache.org
> Cc: tomcat-dev@jakarta.apache.org
> Subject: Functional spec for JNDI Realm
>
> Craig
>
> After a long delay, I'm looking at your proposed functional spec for the
> Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the
> "Adminstrator Login Mode Functionality" section:
>
> > The following approaches should be supported [ for retrieving the roles
> associated with an authenticated user ]
> >
> > Retrieve a specified attribute (possibly multi-valued) from an LDAP
> search expression, with a replacement placeholder
> > for the DN or username of the user.[Current]
> >
> > Retrieve a set of role names that are defined implicitly (by selecting
> principals that match a search pattern) rather
> > than explicitly (by finding a particular attribute value). [Requested]
>
> The existing code certainly implements the first approach, which I assume
> could be rephrased as
>
> Retrieve the values of a specified attribute from all directory entries
> matching an LDAP search filter expression. The search expression is
> constructed by substituting the user's DN and/or username into a string
> pattern specified as the roleSearch configuration property.
>
> However I guess I don't understand what you mean by the second approach. Do
> you have a specific example? I would have thought that the current approach
> covers all use cases (although admittedly the implementation may not be
> optimal for the special case in which role names are held explicitly as the
> values of an attribute in the user's directory entry).
>
> Cheers, John.
>
>
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>