Postgres Pro
Downloads
Home   >   mailing lists

Re: LDAP where DN does not include UID attribute - Mailing list pgsql-admin

From Robert Fleming
Subject Re: LDAP where DN does not include UID attribute
Date
Msg-id 4c0112730909141723q66ecc61fkfbd5aebae71e8130@mail.gmail.com
Whole thread Raw
In response to Re: LDAP where DN does not include UID attribute  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-admin
Tree view


On Mon, Sep 14, 2009 at 4:56 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
On Mon, Sep 14, 2009 at 5:47 PM, Robert Fleming <fleminra@gmail.com> wrote:
> On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Robert Fleming <fleminra@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

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: postgres scripting
Next
From: std pik
Date:
Subject: hardware information