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

Re: LDAP where DN does not include UID attribute

From: Robert Fleming <fleming(at)cs(dot)washington(dot)edu>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: LDAP where DN does not include UID attribute
Date: 2009-09-15 00:23:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
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 <> 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?


In response to

pgsql-admin by date

Next:From: raghu ramDate: 2009-09-15 01:16:13
Subject: Re: sql to show tablespace for indexes
Previous:From: Scott MarloweDate: 2009-09-14 23:56:42
Subject: Re: LDAP where DN does not include UID attribute

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