+1 !!!
Saludos ,
Ignacio J. Ortega
> -----Mensaje original-----
> De: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Enviado el: martes 15 de mayo de 2001 9:46
> Para: [EMAIL PROTECTED]
> Asunto: RE: JNDI/LDAP realm
>
>
> 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. <><><><><><><><><><><><><><><><><><><><><>
> >
>
