Skip site navigation (1) Skip section navigation (2)

Re: LDAP where DN does not include UID attribute

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Robert Fleming <fleming(at)cs(dot)washington(dot)edu>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: LDAP where DN does not include UID attribute
Date: 2009-09-15 07:35:30
Message-ID: dcc563d10909150035l67ba8618h3a11207b1531b9f5@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
On Tue, Sep 15, 2009 at 12:27 AM, Robert Fleming
<fleming(at)cs(dot)washington(dot)edu> wrote:
> On Mon, Sep 14, 2009 at 4:56 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
> wrote:
>>
>> On Mon, Sep 14, 2009 at 5:47 PM, Robert Fleming <fleminra(at)gmail(dot)com>
>> wrote:
>> > On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> >>
>> >> Robert Fleming <fleminra(at)gmail(dot)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.
>
> I'll come up with a patch to support search+bind a la Apache, etc., and
> retain the existing logic as an optimized sub-case.  I think the cost of an
> additional conditional branch instruction will be negligible w.r.t. the LDAP
> bind.  I suppose this should go to the development list.
> I mainly just wanted to confirm with this list that this is a scenario that
> is not currently covered by PostgreSQL.

Yeah, it's really a question of scalability.  If a app is constantly
authenticating then it could be a problem.  The problem stems from
authentication being a bolt on for LDAP, instead of a primary
function, like kerberos.  If it was just username and password, check
out a token, you'd have it easy(ier?), right?

In response to

pgsql-admin by date

Next:From: std pikDate: 2009-09-15 09:58:07
Subject: hardware information
Previous:From: raghu ramDate: 2009-09-15 01:16:13
Subject: Re: sql to show tablespace for indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group