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.
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.
> -----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. <><><><><><><><><><><><><><><><><><><><><>
