On Tue, Sep 15, 2009 at 12:27 AM, Robert Fleming <fleming@xxxxxxxxxxxxxxxxx> wrote: > On Mon, Sep 14, 2009 at 4:56 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> > wrote: >> >> On Mon, Sep 14, 2009 at 5:47 PM, Robert Fleming <fleminra@xxxxxxxxx> >> wrote: >> > On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> >> >> >> Robert Fleming <fleminra@xxxxxxxxx> 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? -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
