Why not having all realm code (JDBC/JNDI/LDAP/JAAS) shared
in a common tomcat subproject ?
ie: jakarta-tomcat-realms
-
Henri Gomez ___[_]____
EMAIL : [EMAIL PROTECTED] (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-----Original Message-----
>From: Steve Downey [mailto:[EMAIL PROTECTED]]
>Sent: Monday, May 14, 2001 6:40 PM
>To: [EMAIL PROTECTED]
>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:[EMAIL PROTECTED]]
>> Sent: Sunday, May 13, 2001 12:58 PM
>> To: [EMAIL PROTECTED]
>> 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" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Cc: <[EMAIL PROTECTED]>
>> 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. <><><><><><><><><><><><><><><><><><><><><>
>
