On Mon, Sep 14, 2009 at 4:56 PM, Scott Marlowe <scott.marl...@gmail.com>wrote:
> On Mon, Sep 14, 2009 at 5:47 PM, Robert Fleming <flemi...@gmail.com> > wrote: > > On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> > >> Robert Fleming <flemi...@gmail.com> writes: > >> > But I would like to authenticate to PostgreSQL using the "uid" LDAP > >> > attribute, > >> > >> What value does that have that would justify doubling the time needed > >> to authenticate? (I presume two LDAP requests will take about twice > >> as long as one...) > > > > That's just the way the company LDAP is setup -- it's out of my control > > unfortunately. > > > > Our schema used to have the uid in the DN, and I always wrote our > enterprise > > software to just do the bind without a search. When the LDAP schema > > changed, my reaction was the same as yours, but when I saw that Bugzilla, > > MediaWiki, etc. accommodate it without flinching, I figured it wasn't too > > uncommon, so I changed my own software. Other software that supports it: > > Tiki wiki, Apache's mod_authnz_ldap, ejabberd. I think I had to tweak > some > > Perl for jabberd <jabberd.org> to handle it. > > > > It might be twice as slow, but if PostgreSQL were smart or configurable > > enough, it could skip the search when not necessary. So performance > needn't > > be impacted. > > On a large ldap schema it's WAY more than twice as slow. A Search is > about 10 to 20 times slower on most ldap servers. I've seen machines > handling 1,000 or more auths per second slow to a crawl due to this > type of change. > First, as I mentioned, I'm not proposing to impose a "search" operation on all users. It could be a configuration option, or it might be possible for PostgreSQL to be smart enough to know that it doesn't need to do a search. FWIW, a quick look at the Apache source code makes me think that they are not concerned with this overhead. Second (only for the sake of argument), I could imagine designing an LDAP server for which this particular search operation is no slower than a bind. (This I say without the benefit of having implemented or administered any LDAP server.) I will probably make the mod myself because of course I won't see this feature in a release in the near future, in any case, and it's an easy change. My goal of writing to this list was mainly to confirm that PostgreSQL is currently *not* able to handle this scenario. Based on the conversation so far I take it that that is a correct assessment? Thanks, Robert