tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject RE: JNDI/LDAP realm
Date Tue, 15 May 2001 07:45:51 GMT
Why not having all realm code (JDBC/JNDI/LDAP/JAAS) shared
in a common tomcat subproject ?

ie: jakarta-tomcat-realms 

-
Henri Gomez                 ___[_]____
EMAIL : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-----Original Message-----
>From: Steve Downey [mailto:steve.downey@netfolio.com]
>Sent: Monday, May 14, 2001 6:40 PM
>To: tomcat-dev@jakarta.apache.org
>Subject: RE: JNDI/LDAP realm 
>
>
>The downside to binding with the supplied credentials is that 
>it chews up a
>file descriptor. For light loads, it's not an issue. For heavy 
>loads, it can
>be a big issue. If the app server binds administratively, you 
>can get by
>with two connections, one for reading and one for writing. Or 
>even one, if
>you're not replicating LDAP.
>
>All in all, making it configurable is probably a good idea.
>
>> -----Original Message-----
>> From: Ellen Lockhart [mailto:elockhart@home.com]
>> Sent: Sunday, May 13, 2001 12:58 PM
>> To: tomcat-dev@jakarta.apache.org
>> Subject: Re: JNDI/LDAP realm 
>> 
>> 
>> I preferred binding to the directory with supplied 
>> credentials because it
>> allows the realm implementation to use an anonymous password 
>> for the rest of
>> what it needs.
>> 
>> To allow for DN's in the directory that may not be composed 
>> of the same
>> attributes as other DN's, one thing I was thinking about 
>> doing to the one I
>> submitted was to configure what the login attribute is (cn, 
>> uid, etc.) and
>> search for it (with anonymous login) to get the dn, then bind to the
>> directory with the resultant DN and the user-entered password to
>> authenticate.  This might be a little less efficient than 
>> just searching and
>> getting the password as well, but is more secure than having the root
>> password to the ldap server where it might be accessible by someone.
>> 
>> 
>> ----- Original Message -----
>> From: "John Holman" <j.g.holman@qmw.ac.uk>
>> To: <tomcat-dev@jakarta.apache.org>
>> Cc: <craigmcc@apache.org>
>> Sent: Sunday, May 13, 2001 5:02 AM
>> Subject: JNDI/LDAP realm
>> 
>> 
>> > The current JNDI realm implementation in Tomcat 4 is based 
>on code I
>> > submitted, which was subsequently modified and committed by Craig.
>> >
>> > Two significant changes he made are:
>> >
>> > - the original code found the DN of the user by searching 
>> the directory.
>> The
>> > current implementation, like Ellen Lockhart's recent submission,
>> determines
>> > the DN by substituting the username into a string.
>> >
>> > - the original code supported a mode in which the user is 
>> authenticated by
>> > binding to the directory with the supplied credentials (as 
>> does Ellen's).
>> > The code for this was removed, with a comment in the commit 
>> log that this
>> > mode should be supported probably in a separate 
>> implementation class.
>> >
>> > I did comment on this in an earlier message, but got no 
>> response - so I'm
>> > trying again now there is another little wave of interest :)
>> >
>> > Determining the DN. The pattern substitution method in the current
>> > implementation is obviously more efficient when applicable 
>> but the search
>> > method is more general. For example, unlike the current 
>> implementation,
>> > search can handle the following common use cases:
>> >
>> > - users are stored within multiple nodes in the directory 
>> (e.g. they may
>> be
>> > held under different
>> > organisational units)
>> >
>> > - the attribute used in distinguished names is not the same 
>> as that the
>> user
>> > enters into the basic authentication dialog box (e.g. the 
>> user might enter
>> > mail address as the username rather than uid; the directory 
>> might use
>> > commonName as a component of distinguished names rather than uid).
>> >
>> > So there are really two orthogonal issues for user 
>> authentication each
>> with
>> > two options:
>> >
>> > - how the dn for the user is determined (configuration template vs
>> directory
>> > search)
>> > - how authentication is done (system login vs binding as the user)
>> >
>> > I think it's important that Tomcat supports the missing 
>> combinations of
>> > options. In fact, the most common strategy when using a 
>> directory for
>> > authentication is probably "search then bind", neither 
>> component of which
>> is
>> > supported by the current implementation.  For example, this is the
>> strategy
>> > taken by pam_ldap and by the auth_ldap Apache module.
>> >
>> > I'd be happy to have a go at adding the missing 
>> functionality, but would
>> > like some feedback first as to whether people think this is 
>> a good idea.
>> > Also opinions as to whether we should have one, two or even 
>> four classes
>> to
>> > implement the different combinations (with multiple classes 
>> maybe derived
>> > from a base JNDIRealm class). We should take into account 
>> which variation
>> is
>> > likely to lead to the simplest and clearest configuration 
>> documentation
>> ...
>> >
>> > John.
>> >
>> >
>> 
><><><><><><><><><><><><><><><><><><><><><>This
electronic mail 
>transmission
>may contain confidential information and is intended only for 
>the person(s)
>named.  Any use, copying or disclosure by any other person is strictly
>prohibited.  If you have received this transmission in error, 
>please notify
>the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
>

Mime
View raw message