5 messages in org.apache.tomcat.devRe: Functional spec for JNDI Realm| From | Sent On | Attachments |
|---|---|---|
| John Holman | Jan 8, 2002 6:24 am | |
| Craig R. McClanahan | Jan 8, 2002 9:08 am | |
| John Holman | Jan 8, 2002 9:39 am | |
| Tony Dahbura | Jan 8, 2002 6:57 pm | |
| John Holman | Jan 9, 2002 1:46 am |
| Subject: | Re: Functional spec for JNDI Realm | |
|---|---|---|
| From: | John Holman (j.g....@qmul.ac.uk) | |
| Date: | Jan 9, 2002 1:46:23 am | |
| List: | org.apache.tomcat.dev | |
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.g....@qmul.ac.uk> To: crai...@apache.org Cc: tomc...@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: <mailto:tomc...@jakarta.apache.org> For additional commands, e-mail:
<mailto:tomc...@jakarta.apache.org>