At 13:49 16/05/01, Steve Downey wrote:
>As I understand it, you can rebind with different credentials, but you can't
>have more than one set of credentials on the same connection. That means
>either synchronizing on the ldap connection, and serializing login, or
>having multiple connections and parallelizing login.
That's my understanding too - and in fact the directory should abort any
pending requests on a connection when a rebind occurs. But I think either
synchronisation or multiple connections/contexts are needed anyway, even if
a system account is used to bind to the directory and that the same
credentials are used throughout.
>Now, this isn't a terrible issue if the code cleans up promptly when done
>authenticating, but it is a resource contention issue.
>
>If the code doesn't clean up promptly, and relies on finalization, then it
>will only fail under load. Usually in some horrible manner that will be
>difficult to trace back to the root cause.
Yes. The initial code makes no attempt at performance - it serialises all
requests through a single directory context.
John
> > -----Original Message-----
> > From: John Holman [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, May 14, 2001 5:55 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: JNDI/LDAP realm
> >
> >
> >
> > ----- Original Message -----
> > From: "Steve Downey" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, May 14, 2001 5:39 PM
> > 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.
> >
> > According to the JNDI tutorial at least, Suns's provider for
> > LDAP v3 is
> > supposed to allow rebinding with a different principal.and
> > credentials while
> > keeping the same directory context and underlying network connection.
> > (Although in practice it doesn't always seem to work quite
> > like that). So
> > it might be possible not to need additional file descriptors.
> > Also, note
> > that the LDAP connection is only needed for a brief period at
> > the beginning
> > of a session when the user first authenticates. Not that the
> > present code
> > attempts to be efficient about reusing directory contexts etc.
> >
> > But perhaps I misunderstand what you are saying.
> >
> > > All in all, making it configurable is probably a good idea.
> >
> > Agreed.
> >
> > >
> > > > -----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. <><><><><><><><><><><><><><><><><><><><><>
> > >
> >
><><><><><><><><><><><><><><><><><><><><><>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. <><><><><><><><><><><><><><><><><><><><><>
